RE: ISSUE-80: namespace for ssn and friends

A key axiom has been left off the explanation, for the Device example (it is in the image):
https://www.w3.org/ns/ssn/Device rdfs:subClassOf  https://www.w3.org/ns/ssn/dul/Device



From: Armin Haller [mailto:armin.haller@anu.edu.au]
Sent: Friday, 14 October 2016 1:41 PM
To: public-sdw-wg@w3.org
Cc: Phil Archer <phila@w3.org>
Subject: ISSUE-80: namespace for ssn and friends

Hi,

After our last SSN meeting we have confirmation that PURL will be maintained by the Internet Archive going forward and we can use the proposed new URI:

https://www.w3.org/ns/ssn/


for the new SSN. For new terms or axiomatically narrowed terms we will need to show fresh implementation evidence.

For terms that remain unchanged we can define an equivalence relation to the old term and can use existing implementations as evidence. In order to not “pollute” the new SSN with equivalence relations to old terms (which are also layered underneath DOLCE inheriting its semantics which we want to avoid), the following proposal how to do that. For each term in the new SSN that is unchanged other than the DOLCE alignment part we do the following:

https://www.w3.org/ns/ssn/dul/Device rdfs:subClassOf http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact

https://www.w3.org/ns/ssn/dul/Device owl:equivalentClass http://purl.oclc.org/NET/ssnx/ssn#Device


Please also refer to the attached picture that summarises the description above graphically and should be easier to comprehend. Then the DUL module needs to be in the normative part of the document, while https://www.w3.org/ns/ssn/Device can be semantically weaker defined in the new SSN. Consequently, it should, in my opinion, also use an annotation that does not refer to DUL, i.e. we would need to rewrite a majority of the annotations, but it is a subClass of a new class defined in the DOCLE module that is equivalent to the old class in the old SSN. I have not received confirmation from Phil yet, but in my opinion for all classes/properties that follow this method we do not need to show new implementations, but pointing to existing proven implementation would be sufficient. However, even if we need to show evidence, all an existing implementation that does not use DULCE has to do is to point to the namespace of the new SSN and we have evidence of an implementation (for all concepts that remain unchanged).

For the SOSA core namespace we have essentially two options left (disregarding the initial MUST dependency of SSN on top of SOSA, i.e. https://www.w3.org/ns/sosa/ssn/):


1.       https://www.w3.org/ns/sosa/: This URI would not have any implications on the status of the core. SOSA could then either be normative, non-normative or a Note. If it is normative, SSN could even import SOSA as envisioned by the ontology modularisation proposal in: http://w3c.github.io/sdw/ssn/#Modularisation. It does not completely follow the URI schema logic that is proposed in the modularisation proposal, since there it was envisioned that SSN strictly imports SOSA (and the namespace is thus https://www.w3.org/ns/sosa/ssn/), but in light of implementation requirements I feel the sentiment in the working group is that we should not make this strong assumption.

2.       https://www.w3.org/ns/ssn/sosa/: This URI structure would somehow undermine the logic that we are following with the DOLCE module, since DOLCE imports SSN, but not the other way. SOSA MUST NOT import SSN, so personally, I would vote for the previous namespace.

In both cases, if a term in SOSA is broader than the term in SSN and consequently broader than in the DOLCE module, I would envision that again, existing implementations would be sufficient (pending Phil’s judgement).

Cheers,
Armin