Include all DTS specific properties in the @contex provided in the JSON-LD response?

[ingoboerner]

In the current "unstable" specification the JSON-LD responses include the context https://github.com/distributed-text-services/specifications/blob/cd287d0b1d18ef98904b42c5fd8c2eba1208c9ce/context/1-alpha1.json. The example of the DTS Entrypoint included in the current "unstable" version includes the property names dtsVersion, collection, navigation and document.

I tried to look them up in the JSON-LD context file, but none of them are defined there: https://distributed-text-services.github.io/specifications/context/1-alpha1.json and also not included in https://github.com/distributed-text-services/specifications/blob/master/context/1.0.0draft-2.json

I am no expert to JSON-LD, but I understand that it is not necessary to include all all properties used in the data to be defined in the @context it, but I was wondering, why properties like download or the now deprecated passage are (still) included, but some of the very custom properties to DTS are not.

[ingoboerner]

Just an additional note (which might go into a separate issue, but is probably hard to solve):

In the current setup of the DTS documentation infrastructure realized by using GitHub pages it seems to be not possible for a (RDF/LD aware?) client to properly dereference the URIs included in the JSON-LD @context.

For example the resource of the class dts:EntryPoint is – according to the included context – identified by the URI https://w3id.org/dts/api#EntryPoint. I would now expect that if I go to the URI I would get more information on this class or find a formal definition in an ontology. But when dereferenced the URI directs back to the GitHub Repository https://github.com/distributed-text-services/specifications/#EntryPoint (which does not help in understanding what the semantics of dts:EntryPoint are). It rather should return an RDF snippet when requesting it via the HTTP-header, or point to a human readable documentation of the class. Or, maybe, at least to the HTML documentation of the EntryPoint, but this would also not work, because the fragment identifier is #entry-endpoint as in https://distributed-text-services.github.io/specifications/versions/unstable/#entry-endpoint and not https://distributed-text-services.github.io/specifications/versions/unstable/#EntryPoint as the JSON-LD would suggest.

[ingoboerner]

I reviewed the JSON-LD contexts in https://github.com/distributed-text-services/specifications/tree/master/context. They do not include all classes and properties that are in the current spec, e.g. regarding classes and object properties (red are the missing ones)

I created a proposal for a JSON-LD context that includes everything that is currently in the spec and consequently references terms defined in an OWL (1) Ontology. Maybe you could review that and tell me what you think.

[hcayless]

Thanks for all your work on this, @ingoboerner. I am going to make some changes (basically make the hydra properties dts properties) and merge your request.

[hcayless]

@ingoboerner After discussing the issue this morning, we decided it's best to have a clean break from Hydra, so what I've done is redefine the hydra properties as dts properties and updated the ontology and the context. It would be great if you could take a look and let us know if you think my changes are correct/sufficient. Thanks!

[PonteIneptique]

@ingoboerner Just a little bump on this topic ;) We are waiting on this to make DTS a release candidate 🥳

[ingoboerner]

Hi, OK, I looked at it. I think, dts:member is good. Only issue here could be that

rdfs:comment "Contains members of a collection."
it are not only members of a collection, but that member is also used to "link" CitableUnits in the response of the navigation endpoint, if I am not mistaken? Currently this would not work, because domain is only dts:Collection and not dts:Resource as well, e.g. https://staging.dracor.org/api/v1/dts/navigation?resource=https://staging.dracor.org/id/ger000001&ref=body&down=1 Here member is used to include the CitableUnits;
so we have to adapt the domain and the range:

dts:member
    a owl:ObjectProperty ;
    rdfs:label "member" ;
    rdfs:comment "Contains members of a collection."
    rdfs:domain [
        a owl:Class ;
        owl:unionOf (dts:Collection, dts:Resource)
     ] ;
    rdfs:range [
        a owl:Class ;
        owl:unionOf (dts:Collection, dts:Resource, dts:CitableUnit) ;
    ] ; 
    rdfs:isDefinedBy <https://w3id.org/dts/api> .

The other new property title must be a a owl:DatatypeProperty because the range is a string and not an object. Same is dts:description, right? This was also hydra:description?

In Hydra hydra:title and hydra:description are subProperties of rdfs:label and rdfs:comment:
This makes sense, so

dts:description 
  a owl:DatatypeProperty ;
  rdfs:subPropertyOf rdfs:comment ;
  ...

dts:title
  a owl:DatatypeProperty ;
  rdfs:subPropertyOf rdfs:label ;
  ...

[hcayless]

That makes sense. Iirc Collections in Hydra are a universal type for anything that can have members, so we should have adjusted when we moved away from Hydra. I'll take a look at it.