Re: ISSUE-80: namespace for ssn and friends

> <http://www.w3.org/ns/ssn/Device> rdf:type owl:Class ;
>
>
> rdfs:subClassOf 
> <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact> .
>
> ØThe first triple is important since it would be defined in the DOLCE 
> alignment ontology. As agreed, we do not want any axioms in the /new 
> SSN/ that rely on DOLCE. In order to give the new SSN device the same 
> meaning as the old one, we would have the subClass relation and the 
> equivalence relation in the DOLCE alignment ontology which then needs 
> to be in the normative part of the recommendation.

Frankly speaking, I am not sure whether we are not trying to do the 
impossible. I absolutely and strongly agree with not having any DOLCE 
related axioms in the new SSN but how exactly will the optional 
alignment work and ensure that we are not generating unintended 
ontological commitments? Any thoughts?

Best,
Krzysztof



On 10/24/2016 10:13 PM, Armin Haller wrote:
>
> See inline comments in red
>
> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
> *Date: *Monday, 24 October 2016 at 10:50 pm
> *To: *Armin Haller <armin.haller@anu.edu.au>, Phil Archer 
> <phila@w3.org>, "public-sdw-wg@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.
>
> 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 
> <https://www.w3.org/ns/ssn/Device>
>
> ØMy interpretation of Phil’s comment is that it is sufficient as long 
> as we do not change the semantics. Phil?
>
> 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> .
>
> ØThe first triple is important since it would be defined in the DOLCE 
> alignment ontology. As agreed, we do not want any axioms in the /new 
> SSN/ that rely on DOLCE. In order to give the new SSN device the same 
> meaning as the old one, we would have the subClass relation and the 
> equivalence relation in the DOLCE alignment ontology which then needs 
> to be in the normative part of the recommendation.
>
> --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 
> <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/ 
> <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
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net