RE: ssn: issue-72 inverse properties in sosa-core and JSON-LD

Somebody (maybe Antoine?) raised the  relevant question about who we are targeting for our work here.   The "JSON" developer as a data consumer  has been a very strong driver for the SDW group's work  as established very early on (please do not ask me to bring up minutes from a year ago). We also need to meet data publishing needs.  While SSN is too complex to meet this JSON need, SOSA-core should not be too complex to meet that need.

So I had a quick look at JSON-LD  https://www.w3.org/TR/json-ld/#relationship-to-rdf 
My interpretation is that, due to the "@reverse" https://www.w3.org/TR/json-ld/#reverse-properties   there is no need to define inverse terms for any properties in sosa-core -- possibly  better avoided as redundant from a json-ld perspective.

I *think* that while  defining a @reverse property in the scope of a JSON-LD context is possible,  the https://www.w3.org/TR/2014/REC-json-ld-api-20140116/#rdf-serialization-deserialization
would fail to work as desirable in either direction with our sosa-core schema document.  I.e. for JSON-LD it seems that the *only* place to define inverse properties is within some reusable JSON-LD 
context or else  in some particular JSON-LD structure, but either way there is no translation rule to/from RDF(S)/OWL that would carry that semantics over the bridge.

 I *think*, though, that  we could write (by hand)  a  reusable JSON-LD context document that could define the inverses we want using  "@reverse"  and this could be done to effectively mirror any "ow:inverseOf" declarations in sosa-core.  Then the round-tripping  of rdf instance data between sosa-core as rdf and sosa-core as json-ld would work. It seems possible that the  translation could even map to a canonical choice for each property of the inverse  pair  (but I am not certain of this --- would require a closer look), so effectively implementing the semantics of "inverseOf" in a very particular circumstance. And I *think* the algorithm to flattening to JSON object  can have the same effect --ie making a canonical  choice for each property of the inverse pair so that the desired "inverseOf" semantics are implemented.

 This is only informed by a quick read, so please feel free to correct me!  

-Kerry

Received on Saturday, 12 November 2016 06:20:43 UTC