JSON-LD hardcodes field type->term type

[seth-shaw-unlv]

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:

1. Make EDTF an actual FieldType and include it in the hard-coded list, OR
2. See if we can override the mapping using a setting somewhere (either extending rdf.mapping or as a jsonld.setting).

Thoughts on either approach?

[dannylamb]

@seth-shaw-unlv Would providing an alter work? That way a module could register new Field Types that it's providing.

[seth-shaw-unlv]

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

      "http://schema.org/birthDate": [
        {
          "@value": "1936-06-uu"
        }
      ]

would become

    "http://schema.org/birthDate": [
      {
        "@value": "1936-06-uu"
      },
      {
        "@value": "1936-06",
        "@type": "http://www.w3.org/2001/XMLSchema#gYearMonth"
      }
    ],

Although, we still don't have a good solution for normalizing date ranges that span more than a single year.

Thoughts, metadata folks? @rosiel or @rtilla1?

[DiegoPino]

My 2 cents
@seth-shaw-unlv So ETDF http://www.loc.gov/standards/datetime/edtf.html is an extension (still a draft?) of https://en.wikipedia.org/wiki/ISO_8601. But to be semantically correct it is not ISO8601, and http://schema.org/birthDate range is schema:Date which is primitive date in ISO8601 format as stated here: https://schema.org/Date

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 edtfdata type) to be in its range would be acceptable. Lastly, you can always go for a string and leave the interpretation to the logic, since nothing of this would make sense in a date-aware SPARQL query anyway

[seth-shaw-unlv]

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.

[seth-shaw-unlv]

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.

[DiegoPino]

@seth-shaw-unlv good to close?
Islandora/jsonld@89910a2
was merged

[seth-shaw-unlv]

@DiegoPino, technically yes. I've commented on EDTF work on this issue, but that work is probably a separate ticket.

[DiegoPino]

Resolved via Islandora/jsonld@89910a2