Explain namespaces and graphs

[dr-shorthair]

In the existing Rec doc, chapter 4 https://www.w3.org/TR/vocab-ssn/#Axiomatization starts with a cursory explanation of the namespaces. The final two paragraphs of the previous section "• Addressing technical developments" briefly mention the axiomatization levels in the two primary graphs.

I think we need a more explicit explanation of our use of namespaces and graphs in the RDF/RDFS/OWL/schema.org implementation of SOSA/SSN, in particular emphasizing

• we use the sosa: namespace for all of the classes and properties previously in SOSA and SSN
• the core classes and properties are defined in sosa.ttl, which we refer to as the SOSA Graph
• the SOSA Graph has very limited axiomatization - only rdf:type , owl:inverseOf , schema:domainIncludes , schema:rangeIncludes plus annotations
• the RDFS and OWL axiomatization of the core classes and properties is in ssn.ttl which we refer to as the SSN Graph - which uses rdfs:subClassOf , rdfs:subPropertyOf, owl:Restriction and other RDFS and OWL features as necessary
• ssn: is no longer used as a namespace for classes and properties - all resources that were in ssn: in the 2017 Rec have been copied to sosa: and the ssn: versions labelled as 'deprecated', though retained in the SSN graph for backward compatibility
• additional features are defined in other graphs implemented in additional RDF files, in particular ssn-system.ttl , sosa-oms.ttl
• where statements are made about a resource that is originally defined in another graph, the predicate rdfs:isDefinedBy is used to point to the 'home' graph - e.g. the axiomatization in ssn.ttl has a lot of sosa:RESOURCE rdfs:isDefinedBy sosa: triples
• we will provide SHACL shapes that provide an alternative way to add rules to the SOSA graph

... more ? ...

[dr-shorthair]

Perhaps Chapter 4 should be re-titled RDF Implementation

[dr-shorthair]

I've had a go at updating chapters 2 and 4 - see

• https://raw.githack.com/w3c/sdw-sosa-ssn/namespaces-and-graphs-doc/ssn/index.html#Modularization (diagram needs redrawing)
• https://raw.githack.com/w3c/sdw-sosa-ssn/namespaces-and-graphs-doc/ssn/index.html#RDFImplementation

and I added OMS in the Normative references

• https://raw.githack.com/w3c/sdw-sosa-ssn/namespaces-and-graphs-doc/ssn/index.html#bib-oms

[maximelefrancois86]

I agree with most of what you propose.

Let me illustrate with excerpts of what would be in these graphs:

in Graph SOSA

sosa:Property a owl:Class ;
   ... 
sosa:ObservableProperty a owl:Class ;
   ...  # would it be unrelated with sosa:Property ?

in Graph SSN

sosa:Property a owl:Class ;
   ...

sosa:ObservableProperty a owl:Class ;
   rdfs:subClassOf sosa:Property ;
   ...

ssn:Property a owl:Class ;
  owl:equivalentTo sosa:Property ;
  owl:deprecated true .

Two issues here:

1. Why don't we allow the use of rdfs:subClassOf in the SOSA Graph if we have both sosa:ObservableProperty and sosa:Property?
2. If I want to work with SOSA + OWL Axioms, I am forced to carry around a whole load of deprecated entities.

To solve the second point, I suggest the following:

• ssn.ttl contains all the triples of sosa.ttl, and adds the the RDFS and OWL axiomatization of the core classes and properties, but it does not declare any of the terms in the ssn: namespace
• a hidden graph, that we don't even need to mention in the specification, ssn-deprecated.ttl, would declare the terms in the ssn: namespace, state that they are deprecated, and define their equivalence to terms in the sosa: namespace.
• we change the .htaccess configuration file at https://www.w3.org/ns/ssn/ such that each term in the ssn: namespace redirects to ssn-deprecated.ttl.

[dr-shorthair]

Two issues here:

1. Why don't we allow the use of rdfs:subClassOf in the SOSA Graph if we have both sosa:ObservableProperty and sosa:Property?

At the moment I'm keeping the SOSA graph consistent with the level of axiomatization that we agreed on for the 2017 version. Adding sub-class axioms into the SOSA graph would be a major change.

2. If I want to work with SOSA + OWL Axioms, I am forced to carry around a whole load of deprecated entities.

Indeed. I left these in the SSN graph so that @kjano deployment KWG - which using some reasoning based on SSN - would be OK. Can we merge this documentation for now, and create a new issue for alternative ways to preserve the backward compatibility required for KWG?