-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON-LD hardcodes field type->term type #916
Comments
@seth-shaw-unlv Would providing an alter work? That way a module could register new Field Types that it's providing. |
As for the EDTF typing, because none of the standard date formats (xs:date, xs:gYear, and xs:gYearMonth) allow uncertainty or ranges, we should keep the EDTF value as a string type, but I think it makes sense to add normalized versions. E.g. the JSON-LD
would become
Although, we still don't have a good solution for normalizing date ranges that span more than a single year. |
My 2 cents I think you would be better of by having an actual date in schema.org/birthDate and then another, non-schema.org (Time ontology does not mention EDTF?, what does LoC recommend there?)predicate for your uncertainty date. Here is some more info from LoC http://id.loc.gov/datatypes/edtf.html Reading that it seems ETDF is defined as a SkosConcept, so any custom, or existing date predicate coming from other ontologies (or one you define) that allows that data type (SkosConcept or the actual |
Yes, EDTF is being included in the ISO 8601 revision (ISO 8601-1). It was supposed to be published sometime in 2018 but it appears to have been pushed out until 2019-02. I created the EDTF widget and formatters because our library is already using it for dcterms:created (so schema:birthDate may have been a poor example, but a lot of our Person agents have approximate dates). One thing I should note is that xs:gYear, xs:YearMonth, and xs:date are ISO 8601 conformant, so I still want a hook that will update the type based on which date format we are using. What remains is addressing approximate and uncertainty indicators ('~', '?', and 'u'). Perhaps I should add an option to the EDTF widget to optionally enforce ISO 8601 dates in case you want to use EDTF with any predicates requiring schema:Date. E.g. birth date where the existing Drupal datetime field is too restrictive (doesn't permit year-month without the day) but the predicate doesn't allow approximation and uncertainty. Alternatively, we find a new Person agent predicate for dates that is more permissive; although I think a lot of users want the SEO benefits of using schema.org. |
To clarify my hook reference in the last comment, I have a working hook_jsonld_alter_normalized_array() implementation that allows me to update the '@type' based on which format the date matches. |
@seth-shaw-unlv good to close? |
@DiegoPino, technically yes. I've commented on EDTF work on this issue, but that work is probably a separate ticket. |
Resolved via Islandora/jsonld@89910a2 |
I created new widgets and formatters for a plain-text field in controlled_access_terms to create Extended Date Time Format (EDTF) support. However, the JsonLdContextGenerator assumes all fields are strings unless they are included in a hard-coded mapping. This means that the ETDF dates are typed as strings.
I can imagine two ways of addressing this:
Thoughts on either approach?
The text was updated successfully, but these errors were encountered: