Re: State of SSN: arguments in favour of a single name and namespace, proposal, the SEAS example, proposal of action

Hi Maxime,

> 2.a Well I'm just telling you how I actually felt. You cannot disagree 
> with the fact that I felt this way.
> 2.b On the other hand, I know you and Armin were not very happy with 
> the name SOSA itself. Is SOSA some kind of brand you want to keep ? 
> Wouldn't it be acceptable for you to rename it "SSN Vocabulary", or 
> "SSN Light Profile" ?
> 2.c So to put it simply, instead of simplifying something that exists 
> and is too complicated, we rather add something new. Is that it ?
>

I am not disagreeing with your feelings but with the interpretation 
about being twice as complex :-).  Btw, I am happy with the name SOSA 
and Armin also supports it. This must be a misunderstanding. We also 
revisited the name SOSA over and over again, lets not reopen this 
discussion.

> 5.a Here again, I'm just telling you how I feel. My fears and hope. 
> That's not a scientific argument, but other potential users may feel 
> the same.
> 5.b It depends on how you define "incompatible". SOSA adopts new names 
> for the same concepts that were there before, and sometimes new 
> definitions. You could say it's just *new* and unrelated to SSN (and 
> compatible with it therefore). But from my point of view, what I see 
> is there may be issues.
> 5.c. I really thought what we commonly mean by backward compatibility 
> is that I wouldn't even need to change the prefix declaration ? I 
> thought the old SSN namespace will redirect to the IRI of the ontology 
> document that is backward compatible with the old SSN ?
> 5.d Actually, I personally don't really care about point 5.c, the SEAS 
> ontologies already import the new https://www.w3.org/ns/ssn/ 
> namespace. It could be problematic for some hypothetical legacy system 
> that uses the old namespace and ontology axioms though.

I am not arguing about your feelings but making arguments that your old 
work is still valid as old-SSN has not changed.  New-SSN will differ in 
many regards from old-SSN because we have changed axioms and also 
removed many, many of them. This may or may not affect your specific 
ontology and data depending on whether you made use of these parts of 
SSN or not. New-SSN and old-SSN entailment differs.  New-SSN has its own 
new namespace. The existence of SOSA does not affect your data at all.

Cheers,
Jano



On 02/02/2017 10:30 AM, Maxime Lefrançois wrote:
> Hi Jano,
>
>     > -1 for SOSA and SSN having the same namespace
>
>
> Sorry, see my answer to Kerry, this is an unfortunate typo:
> -1 for SOSA and SSN having separate namespaces
> +1 for SOSA and SSN having the same namespace.
>
>
>     >  1. Communication-wise, and as a WG member, I would argue that a
>     > single namespace and a single name "SSN" demonstrates that the group
>     > is unified, whereas 2+ namespaces and 2+ names (SSN and SOSA)
>     > demonstrates the group is split in two. This is my impression and
>     > could the the impression of other people exterior to the group.
>
>     I think this is really a misunderstanding of namespaces. The SDW will
>     also use different namespaces and nobody would argue that we are not
>     unified simply because TIME and SSN do not share a common namespace.
>
>
> 1.a TIME and SSN talk about different domains. They where introduced 
> in different documents, by different people. That's a historic 
> difference.
>
> 1.b SSN and SOSA talk about the same domain. I strongly believe that 
> using two different namespaces brings more confusion, and less 
> usability, contrary to what has been said before. Let me just point to 
> a recent email on this list [1]:
>  - Phil: What's the difference between sosa:hosts and 
> sosa:attachedSystem ? Do we need both?
>  - Jano: SOSA should not have an attachedSystem relation. Do you mean SSN?
>
> If choosing what prefix should be used for ***:attachedSystem is even 
> unclear to WG members that are highly involved such as Phil, how do 
> you expect the lambda user not to be confused ?!?
>
>
>     >  2. Name-wise, as a user of the SSN ontology, I actually expect that
>     > the outcome of this group is a simplified SSN. The name "SSN" is
>     known
>     > to me. So when I see there is now SOSA *and* SSN, I think the
>     outcome
>     > of the group is twice as complex that it was before. This is
>     discouraging.
>
>     I absolutely disagree with this statement and I cannot follow your
>     argumentation. The SOSA is something new, this has nothing to do with
>     SSN being known. We are not taking SSN away in any. That said, the new
>     SSN is going to be pretty different from the old SSN so maybe it
>     is good
>     to make this very clear in all possible ways we can.
>
>
> 2.a Well I'm just telling you how I actually felt. You cannot disagree 
> with the fact that I felt this way.
> 2.b On the other hand, I know you and Armin were not very happy with 
> the name SOSA itself. Is SOSA some kind of brand you want to keep ? 
> Wouldn't it be acceptable for you to rename it "SSN Vocabulary", or 
> "SSN Light Profile" ?
> 2.c So to put it simply, instead of simplifying something that exists 
> and is too complicated, we rather add something new. Is that it ?
>
>
> 3. You did not comment on argument 3 does this mean you accept it ?
>
>
> 4. You did not comment on argument 4 does this mean you accept it ?
>
>
>     >  5. On a very personnal level, I spent much effort making so
>     that the
>     > SEAS ontologies use the SSN terms properly, and are compatible with
>     > the SSN ontology. I have been quite discouraged when I saw that new
>     > name "SOSA", and all the incompatibilities that seemed to arise with
>     > SSN. I was afraid it would ruin my efforts in being compatible with
>     > the SSN ontology. The SEAS ontologies are an example of usage of the
>     > SSN ontology, and I really hope they will remain compatible with the
>     > new SSN.
>
>     Maxime. This is where the trouble starts. SOSA and SSN are *not*
>     incompatible. Kerry will of course state this over and over again but
>     this does not make it true. That said, new-SSN is not the same as
>
>     old-SSN so you may have to revisit your ontology if you want to remain
>     compatible with the new SSN which has a new URL as well so your
>     old work
>     using the old SSN is *not* damaged in any way.
>
>
> 5.a Here again, I'm just telling you how I feel. My fears and hope. 
> That's not a scientific argument, but other potential users may feel 
> the same.
> 5.b It depends on how you define "incompatible". SOSA adopts new names 
> for the same concepts that were there before, and sometimes new 
> definitions. You could say it's just *new* and unrelated to SSN (and 
> compatible with it therefore). But from my point of view, what I see 
> is there may be issues.
> 5.c. I really thought what we commonly mean by backward compatibility 
> is that I wouldn't even need to change the prefix declaration ? I 
> thought the old SSN namespace will redirect to the IRI of the ontology 
> document that is backward compatible with the old SSN ?
> 5.d Actually, I personally don't really care about point 5.c, the SEAS 
> ontologies already import the new https://www.w3.org/ns/ssn/ 
> namespace. It could be problematic for some hypothetical legacy system 
> that uses the old namespace and ontology axioms though.
>
> -----
>
> I won't go any further in the exponential growth of arguments.
>
> Best,
> Maxime
>
> [1] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0018.html


-- 
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