- From: Armin Haller <armin.haller@anu.edu.au>
- Date: Tue, 25 Oct 2016 20:52:54 +0000
- To: "janowicz@ucsb.edu" <janowicz@ucsb.edu>, Kerry Taylor <kerry.taylor@anu.edu.au>, Phil Archer <phila@w3.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <284338A5-6E79-46C3-BA94-7EF4A4A2CD03@anu.edu.au>
My first proposal addresses this and leaves all the DOLCE axioms and alignment to the old SSN in the DOLCE alignment ontology which the new SSN does not directly import, but if you want is available to you and is part of the normative part of the document. That solves two problems, implementation evidence of old, but unchanged SSN terms can be provided, while the new SSN ontology does not have any ontological commitment to DOLCE (as long as you don’t import the DOLCE alignment).
From: Krzysztof Janowicz <janowicz@ucsb.edu>
Reply-To: "janowicz@ucsb.edu" <janowicz@ucsb.edu>
Date: Tuesday, 25 October 2016 at 4:32 pm
To: Armin Haller <armin.haller@anu.edu.au>, Kerry Taylor <kerry.taylor@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
<http://www.w3.org/ns/ssn/Device><http://www.w3.org/ns/ssn/Device> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact><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><mailto:kerry.taylor@anu.edu.au>
Date: Monday, 24 October 2016 at 10:50 pm
To: Armin Haller <armin.haller@anu.edu.au><mailto:armin.haller@anu.edu.au>, Phil Archer <phila@w3.org><mailto:phila@w3.org>, "public-sdw-wg@w3.org"<mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org><mailto: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
Ø 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><http://www.w3.org/ns/ssn/Device> rdf:type owl:Class ;
rdfs:subClassOf <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#DesignedArtifact><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><mailto:phila@w3.org>; public-sdw-wg@w3.org<mailto: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
--
Krzysztof Janowicz
Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060
Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 25 October 2016 20:53:32 UTC