RE: ISSUE-80: namespace for ssn and friends

>That’s actually good news. You are saying if we find implementation evidence where the term is used with looser semantics, that is evidence for us to define the term with those looser semantics (and reference the specific implementation). Speaking without evidence, I believe there would be several cases of that, i.e. SSN being used without DULCE or even violating some DULCE axioms.

That could  well be. Would 2 examples be good enough in this case – or would we need some evidence   that satisfied an adjective like “often” or “mostly”?


>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


>https://www.w3.org/ns/ssn/Device  rdfs:subClassOf  https://www.w3.org/ns/ssn/dul/Device




or saying it directly in the new SSN ontology:

>https://www.w3.org/ns/ssn/Device rdfs:subClassOf  https://www.w3.org/ns/ssn/dul/Device


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




I personally prefer the first approach as it would avoid having all these equivalence axioms in the new SSN.

Certainly the former, for the purpose of avoiding the equivalence axioms in the “new ssn” would be preferable.
However, I think (my own interpretation) Phil has suggested that  the former will not serve the purpose.

I.e for the former 3 triples:  you cannot use existing  implementation of http://purl.oclc.org/NET/ssnx/ssn#Device to establish implementation of its subclass https://www.w3.org/ns/ssn/Device




For the latter 2 triples:  the last one seems ok to reuse implementations of old Device all on its own,  so the first triple of the 2  seems entirely redundant, or alternatively does it have some purpose in association with the first triple of the former 3? Maybe it makes sense sitting in the Dolce alignment ontology rather than in the ssn ontology, but I can’t figure the value-add there, either. For the dul alignment we only need

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

or, rephrasing more precisely (copied from https://github.com/w3c/sdw/blob/gh-pages/ssn/ssn_separated/dul-alignment.owl)
<http://www.w3.org/ns/ssn/Device> rdf:type owl:Class ;


rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact> .

--Kerry

From: Armin Haller [mailto:armin.haller@anu.edu.au]
Sent: Monday, 24 October 2016 4:43 PM
To: Phil Archer <phila@w3.org>; public-sdw-wg@w3.org
Subject: Re: ISSUE-80: namespace for ssn and friends


That’s actually good news. You are saying if we find implementation evidence where the term is used with looser semantics, that is evidence for us to define the term with those looser semantics (and reference the specific implementation). Speaking without evidence, I believe there would be several cases of that, i.e. SSN being used without DULCE or even violating some DULCE axioms.



In any case, we still have two implementation choices for making the equivalence relation work (also for unchanged terms), either in an alignment part of the SSN, i.e. in the DULCE alignment as presented in my earlier email:



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


https://www.w3.org/ns/ssn/Device  rdfs:subClassOf  https://www.w3.org/ns/ssn/dul/Device




or saying it directly in the new SSN ontology:

https://www.w3.org/ns/ssn/Device rdfs:subClassOf  https://www.w3.org/ns/ssn/dul/Device


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




I personally prefer the first approach as it would avoid having all these equivalence axioms in the new SSN.



Any other opinions on how to implement the equivalence relation to old SSN terms (in order to reuse implementation evidence)?



On 19/10/16, 10:46 pm, "Phil Archer" <phila@w3.org<mailto:phila@w3.org>> wrote:



    Armin, Kerry, everyone,



    I've looked at this and discussed it with Kerry on our chairs' call on

    Monday.



    My understanding is:

    - you have the original terms at the old namespace that are widely

    implemented;

    - you want to begin using a new (shorter, better looking) namespace;

    - you want to take advantage of the move and amend the definitions (by

    loosening the semantics a little);

    - as part of this you want to extract the terms in another namespace

    that you don't control but assert relationships to them.



    And then say that your implementation evidence for the new terms is that

    the old ones were widely implemented.



    No.



    At least, not in that formulation.



    My original suggestion of asserting owl:equivalent(Class|Property) was

    based on the assumption that the definitions have not changed, i.e. that

    the new and old terms were indeed equivalent. In that case, the

    equivalence relationship holds and the actual namespace used becomes

    irrelevant.



    Remember the goal: to show the Director and the W3C Membership that your

    work is implemented.



    Now that *might* give you a bit of a way forward.



    Why do you want to loosen the semantics? I can think of two reasons (no

    doubt there could be more):



    1. Because you notice that the actual usage of the terms doesn't match

    your original definition and therefore you're essentially playing catch

    up. In this scenario you have implementation evidence.



    2. Because you've tried working with the old definitions but have found

    problems and think the new definitions are better/more suitable. In this

    scenario, you will need to adduce new implementation evidence.



    Sorry to be the bearer of bad news. If I have misunderstood something

    important, shout.



    One bit of good news, you *don't* need to prove that terms defined

    elsewhere are implemented. And if those terms are well managed and

    stable, then the Director is likely to approve your making a normative

    reference to them. See https://www.w3.org/2013/09/normative-references


    for full details of the policy.



    Phil.



    On 14/10/2016 03:40, Armin Haller wrote:

    > 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

    >



    --





    Phil Archer

    W3C Data Activity Lead

    http://www.w3.org/2013/data/




    http://philarcher.org


    +44 (0)7887 767755

    @philarcher1