Re: ISSUE-80: namespace for ssn and friends

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

Received on Wednesday, 19 October 2016 11:46:13 UTC