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

I would be very happy to have this  resolved outside ssn telcos . 

> ), I am not intending to table the naming issue until our F2F.

Also good by me. But soliciting wider views before that point would be helpful.  Would you like me to start a thread? We do have  several  ideas proposed already but they are widely scattered.
This can be entirely separated from the namespace question, as whether there is one namespace or two, we still need names for our modules  and something we can write about in our spec, right?

On a lighter note, I find that sosa means " fucking chief keef nigga." And also " Smoking On Something Amazing." And " cocaine that is meant to be snorted from a stripper's buttcrack."  All rather offensive I think! http://www.urbandictionary.com/define.php?term=sosa


Kerry


-----Original Message-----
From: Armin Haller 
Sent: Monday, 6 February 2017 11:59 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; Phil Archer <phila@w3.org>; Maxime Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: Point of objection RE: State of SSN: arguments in favour of a single name and namespace, proposal, the SEAS example, proposal of action

I have pointed out in my email from Mon, 23 Jan 2017 02:25:42 +0000 that this issue is indeed *unresolved*. However, I have argued in the same email that there was no *strong* objection in the F2F against SOSA (and no one has raised their voice to say otherwise). There is potentially your objection, Kerry, but I am not sure if it is against the name or the fact that it is a different namespace (which is a separate issue to be resolved) and that it is used as the prefix in SOSA. I have further argued that we have much more pressing issues that need our attention rather than wasting our valuable telco time on preferences for names, and further, I recall Phil shouting out in the telco that we need to find a strong reason to create another and at the same time retire an already W3C created namespace. Unless SOSA is offensive in some language or we decide on only using one namespace (a much more important issue to resolve), I am not intending to table the naming issue until our F2F. 

On 5/2/17, 6:36 pm, "Kerry Taylor" <kerry.taylor@anu.edu.au> wrote:

    >And I note it was in fact  "SSN Core" as originally proposed to the group by you in May 2016.  Indeed it remains in your proposal as ssn core. I am sure that was only  intended as a placeholder, as "sosa " is now.  If I recall the  name change to sosa happened entirely off list, on github commits.  I cannot even find it as a github issue (although it was clearly called SANDA for a while there).
    https://www.w3.org/2015/spatial/wiki/SSN_core_modules

    
    Since then, a good few people have asked for the name to be considered. 
    
    Why don’t we spend about one week proposing ideas, put it on the agenda for a meeting in a week from now, and really do decide ? Make  a clear email track through an appropriate subject line and ask people to make comment and vote ---  it does not need a  valuable meeting slot and indeed has the benefit of bringing in the rest of the SDW group.   Or we could put it on the agenda for the F2F. 
    
    > it is in all our emails (that W3C stores forever), all our wiki pages, the entire github history, our draft, notes from F2F meetings, the issue tracker, and so forth.
    Not quite.  Jano, I  think you are saying that you are indeed very fond of "sosa" . Is it possible that some others are not?
    
    We can use  issue-84 to track it.
    -Kerry
    
    -----Original Message-----
    From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu] 
    Sent: Sunday, 5 February 2017 3:56 PM
    To: Kerry Taylor <kerry.taylor@anu.edu.au>; Phil Archer <phila@w3.org>; Maxime Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List <public-sdw-wg@w3.org>
    Subject: Re: Point of objection RE: State of SSN: arguments in favour of a single name and namespace, proposal, the SEAS example, proposal of action
    
    > (1) The name for the core:
    >
    > The question was asked https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0050.html (by me) in response to various discussions (off record) at Lisbon -- although perhaps some of it made its way into the minutes as it was raised (not by me) during the sosa discussion.
    > I did not mean to put the question in that email , only to ask that it be put. Nevertheless there are a few responses (actually 2 for sosa and 2 for not). And it was never put.
    > It is also raised  in the issue tracker as issue-102 well before the WD.  Indeed that issue should have been recorded in the WD -- but nobody working on that part of the spec bothered, I guess, to put it in.
    >
    > Yes, "SOSA" was written into the WD  in those last hectic weeks,  but given that the issue was raised and requested to be discussed and was not --- surely it is fair enough to still consider it unresolved (at least that it what I assumed when I voted for the WD -- I cannot speak for others).?  And it was raised again by yet another member in the past week.
    
    Kerry, let's move on. We have used SOSA for 8+ months now; it is in all our emails (that W3C stores forever), all our wiki pages, the entire github history, our draft, notes from F2F meetings, the issue tracker, and so forth. We are running out of time, lets move forward.
    
    Thanks,
    Jano
    
    
    On 02/04/2017 08:44 PM, Kerry Taylor wrote:
    > Phil,
    >
    > (1) The name for the core:
    >
    > The question was asked https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0050.html (by me) in response to various discussions (off record) at Lisbon -- although perhaps some of it made its way into the minutes as it was raised (not by me) during the sosa discussion.
    > I did not mean to put the question in that email , only to ask that it be put. Nevertheless there are a few responses (actually 2 for sosa and 2 for not). And it was never put.
    > It is also raised  in the issue tracker as issue-102 well before the WD.  Indeed that issue should have been recorded in the WD -- but nobody working on that part of the spec bothered, I guess, to put it in.
    >
    > Yes, "SOSA" was written into the WD  in those last hectic weeks,  but given that the issue was raised and requested to be discussed and was not --- surely it is fair enough to still consider it unresolved (at least that it what I assumed when I voted for the WD -- I cannot speak for others).?  And it was raised again by yet another member in the past week.
    >
    >
    > (2) previous implementation and overriding issues:
    >
    >> desire to build on previous implementation is so skewing the discussion that it is damaging. I would feel a lot more comfortable if we all-but forgot about old SSN for now, and then come back to it once the overriding issues have been resolved.
    >
    > I get this. But it is too narrow to think about this discussion as being driven by 'previous implementation" . SOSA is dramatically new. It bears very little resemblance
    > to O&M (and by O&M I refer to the OGC standard)  to SSN or to anything else.   The mapping table (to  which I have contributed )  is misleadingly simple as it is only about (a small subset of) the descriptive annotations attached to  some classes and properties. It is useful as it is, but falls far short of an analysis of the difference in meaning of the terms between sosa and ssn. I know this because I have done at least a partial analysis and raised issues on the tracker accordingly (as was requested by the chair). I am not going to speak for others, but a good few people have made similar remarks on the list. SOSA is indeed  very simple, quite small, and is reasonably ok as it stands in a self-contained way.  It will be used. But the  "overriding issues" as I see it are all about  how it behaves as a '"core" of ssn that is was always intended  to be -- in fact a "module" of ssn that forms the core.  Actually , SSN is much closer to O&M than SOSA  is-- ssn reuses O&M terms almost everywhere it can  wheras SOSA does not (again, see tracker issues for each SOSA term). Should ssn go backwards in this way in order to use SOSA terms with no heritage at all? And SOSA fails to acknowledge OGC's sensorml at all (unlike ssn).  SSN also reuses from several other ontologies and vocabularies  in the area ( the standard VIM, & MMI are the main ones).
    >
    > SOSA introduces  only sampling and actuation  that  are not  in ssn.  They should also be addressed in  ssn -- deepening according to our modular design.
    >
    > Anyway, this is not about reusing implementations. It is about how ssn and sosa play nicely, and we are a long way from solving that , see https://www.w3.org/2015/spatial/track/issues/139    issue-139.  In my opinion this IS the "overriding issues".
    >
    > Btw -- one disappointing but perhaps quick  way this could go is to divorce sosa and ssn entirely (my "failure" option as I have called it before). Separate specs and they just don't play together.  Then it is easy to modularise  ssn   and to extract a core, taking advantage of the learning we have made around sosa, and without  having to deal with all the incompatibilities.  At this point I have to see this as a serious option.
    >
    > -Kerry
    >
    > -----Original Message-----
    > From: Phil Archer [mailto:phila@w3.org]
    > Sent: Friday, 3 February 2017 9:51 PM
    > To: Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; Maxime 
    > Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List 
    > <public-sdw-wg@w3.org>
    > Subject: Re: Point of objection RE: State of SSN: arguments in favour 
    > of a single name and namespace, proposal, the SEAS example, proposal 
    > of action
    >
    >
    >
    > On 02/02/2017 23:50, Kerry Taylor wrote:
    >> Ø  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 ?
    >>
    >> That’s the plan – as it was suggested by Phil who also explained that it can be done from a W3C perspective and purl perspective. Is this controversial and needs a vote? I would be happy to take an ACTION, but I thought this would be a very late step  in our process so as to not force people to use their  current ssn while it is still unstable.
    > I did say that, yes. However, it seems to me that the understandable desire to build on previous implementation is so skewing the discussion that it is damaging. I would feel a lot more comfortable if we all-but forgot about old SSN for now, and then come back to it once the overriding issues have been resolved.
    >
    >
    >> Ø  We also revisited the name SOSA over and over again, lets not reopen this discussion.
    >>
    >>
    >>
    >> Ahhhhh,  I beg to differ.. It was something that was declared decided many times when it was questioned, but that does not make it decided.  The question has in fact never been asked, let alone revisited, despite the fact that I asked it to be discussed and despite the fact that several people have expressed some concern with “SOSA” (and I am not going to speak for their opinions.)   Can you point please to some evidence that it was decided? And note that I asked it to be dicsussed well before it was written into the current WD, without discussion, so I’m just covering here for a possible statement  that  we all agreed with the evidence that it is in the current WD that we voted for.
    >>
    >
    > My evidence that the name SOSA was agreed upon, and that it provides a 
    > lightweight core beyond which SSN provides more detail, is the 
    > document published with the consent of the whole WG
    >
    > https://www.w3.org/TR/2017/WD-vocab-ssn-20170105/

    >
    > in which I find:
    >
    > "The Sensor, Observation, Sample, and Actuator (SOSA) ontology is one of the modules provided by the Semantic Sensor Network ontology. It acts as the core building block of SSN around which all other classes and relationships evolve."
    >
    >
    >
    >>
    >> Btw “ssn core” has been proposed. I’m quite fond of the  “ssn light” idea or better still “ssn lite?”
    >>
    >> Ø  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.
    >>
    >> Its ok my skin is getting very thick here – I will not take the offence that, frankly, looks rather intended.
    >>
    >> Kerry
    >>
    >>
    >> From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
    >> Sent: Friday, 3 February 2017 5:39 AM
    >> To: Maxime Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List 
    >> <public-sdw-wg@w3.org>
    >> Subject: 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<mailto:jano@geog.ucsb.edu>
    >>
    >> Webpage: http://geog.ucsb.edu/~jano/

    >>
    >> Semantic Web Journal: http://www.semantic-web-journal.net

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

Received on Monday, 6 February 2017 01:37:25 UTC