Re: State of SSN

Hi All,

Thanks Armin for the nice summary!

Please note however that option 3 would contradict our own figures and 
draft as pointed out by Phil and this figure (and text) has been around 
for a year now.

Options 1 and 2 are what we need and as SSN imports SOSA anyway, 2 may 
be easier solution.

Wrt to the comments, I agree with the idea in general (and proposed it 
myself before) but think we need to be very, very careful here. 
*Abstract* comments are almost never a good idea and may actually hurt 
SOSA *and* SSN. Again, just to be clear about this, ideally we would 
have the same comment but this comment has to be on a level that is 
directly understandable and usable, i.e., not too abstract.

Frankly speaking, I am not so happy with having them reworked all at a 
time by a single person and then presented. Why don't we use the next 
2-3 telco's to do this together class by class  as a group so that we do 
not have to re-discuss them afterwards over and over again to find a 
compromise. We are really running late by now :-)

Cheers and thanks again!
Jano

P.s. Let us also please switch back to a mode where everybody 
participates regularly and does not merely jump in a few times per year 
to revisit decisions taken months ago, and let us also all work in a 
constructive and supportive atmosphere. We have a great and impactful 
product and we are all interested in getting it in the best possible shape.



On 01/25/2017 03:36 PM, Armin Haller wrote:
>
> Hi Phil,
>
> Thanks for raising these points. I had a longer F2F conversation with 
> Kerry yesterday to discuss her concerns around the SOSA/SSN alignment 
> and the more general issue she raised with 
> https://www.w3.org/2015/spatial/track/issues/139. I think I now 
> understand her preference, which I will outline in this email. Before, 
> I want to more clearly outline the options we have in terms of 
> alignment between SOSA and /SSN new /as of Point 6 from Phil below, 
> seeing SOSA as the core as already outlined in the first working draft.
>
> _Option 1: SSN new imports SOSA *and* equivalence/subclass/subproperty 
> relations are defined in SSN_: In this option both ontologies use a 
> separate namespace and /SSN ne/w introduces its own classes/properties 
> (in its own namespace) even for concepts/properties that are common to 
> both ontologies, while doing so asserting equivalence and 
> subclass/subproperty relations for those classes that are common and 
> where appropriate.
>
> _Option 2: SSN new imports SOSA *and* “extends” classes/properties 
> from SOSA: _In this option both ontologies use a separate namespace, 
> but /SSN new/ extends SOSA, meaning /SSN new/ uses the SOSA namespace 
> for concepts/properties that are shared between SOSA and /SSN new/ and 
> “extends” (narrows) them with stronger OWL axiomatizations.
>
> _Option 3: SSN does not import SOSA *and* alignment between SOSA and 
> SSN is defined in a separate file/namespace:_ This approach is similar 
> to how we align /SSN new/ to DULCE, i.e. the alignment is in a 
> separate file with its separate namespace.
>
> Although my personal preference from the beginning was on Option 2, my 
> belief was that some group members are against this option, in 
> particular, Kerry, and I was under the working assumption that at best 
> we will achieve Option 3. In my discussion with Kerry yesterday she 
> made it very clear that she prefers _direct usage of SOSA 
> classes/properties in SSN new_. This includes the introduction of 
> properties in /SSN new/ that are defined in SOSA for simplicity 
> (traversing a property path of SSN new) while adding axioms to ensure 
> the equivalence of these simplified properties to a property path. 
> This also means that rdfs:comments will be shared between SOSA and 
> /SSN new/. Since neither of the rdfs:comments in our mapping table on 
> the wiki (https://www.w3.org/2015/spatial/wiki/Mapping_Table) 
> <https://www.w3.org/2015/spatial/wiki/Mapping_Table%29> are yet 
> particularly suited for this purpose, the proposal was:
>
> -To create one very abstract description for each shared concept that 
> _DOES NOT_ refer to classes/properties (i.e. using capital letters or 
> camel casing), but uses English natural language. This rdfs:comment 
> can then be _supplemented by annotation properties_ in the two 
> respective namespaces of SOSA and SSN new. These annotation properties 
> can add examples, refer to classes and properties in the respective 
> namespace using capital letters and describe the stronger semantics as 
> required by /SSN new/.
>
> *If there is no objection from the group, I have volunteered to start 
> with such an abstract description for the rdfs:comments in the mapping 
> table. *I cannot guarantee to finish by our meeting next week, but I 
> will attempt to at least finish some of those.
>
> Beyond that, the agreement with Kerry was that we continue (in the 
> phone calls) with addressing the issues that have been already 
> identified (by her) in the issue tracker in the alignment between SOSA 
> and /SSN new/.
>
> Kind regards,
>
> Armin
>
> On 25/1/17, 11:28 pm, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au> wrote:
>
>     Thanks Phil -
>
>     Just want to comment on your item 2.
>
>     SOSA is not 'inspired by O&M' any more than it is by any of the 
> other prior work. It was an attempt to define a core with lightweight 
> semantics for an audience interested in describing observations, 
> actuation or sampling. The hope was that it could also serve as a core 
> for more semantically rich vocabularies, along the lines proposed by 
> Jano (aka vertical and horizontal modularization). So the scope of 
> SOSA is broad but it is axiomatically shallow - deliberately not much 
> more than schema-org style. Certainly it picks up some ideas from O&M, 
> in particular the notion of Samples, but it also picks up ideas from 
> IoT (Actuators) and SSN (Platform, properties of Sensors). SOSA is 
> definitely not something that has just come from the O&M camp.
>
>     Simon
>
>     -----Original Message-----
>
>     From: Phil Archer [mailto:phila@w3.org]
>
>     Sent: Wednesday, 25 January, 2017 20:41
>
>     To: SDW WG Public List <public-sdw-wg@w3.org>
>
>     Cc: Scott Simmons <ssimmons@opengeospatial.org>; Francois Daoust 
> <fd@w3.org>
>
>     Subject: State of SSN
>
>     Dear all,
>
>     As team contact for the WG, my role is not necessarily to get 
> involved in every aspect of each of our deliverables. As is abundantly 
> clear from our discussions over the last couple of years, the WG 
> members are the domain experts, not me. But, all is not well in the 
> state of SSN and so I feel that I need to take a more active position. 
> My mail on Monday [1] is part of that.
>
>     My understanding of the current situation is likely to be less 
> than 100% accurate - I know that - but what I see is:
>
>     1. There is a lot of prior work that predates the WG: SSN, O&M, Dolce.
>
>     2. There is SOSA, which is, I think I'm right in saying, largely 
> inspired by the work to represent O&M in OWL and create a simple 
> version for wider use.
>
>     3. There is a very understandable desire to see this work become a 
> formal standard - that's what we're chartered to do. This entails 
> gathering evidence of usage. But the problem is that the evidence that 
> exists is from earlier work. What's being done now might be too new 
> and we may not be able to gather that implementation evidence. That 
> would be a pity but it's better than a bad design driven by process. 
> SSN has a reputation for being too complicated so let's not hesitate 
> to simplify it.
>
>     4. The published document states clearly that SOSA is the core and 
> that SSN is an outer ring, with O&M and Dolce Ultra Lite alignments 
> outside both.
>
>     5. There is a debate about whether the alignments, especially with 
> O&M, should be normative. In favour: O&M is a formal standard and it 
> feels right to me that it should be but I'm open to persuasion either way.
>
>     6. There is a debate about whether the SOSA-SSN relationship 
> should be couched as sub classes/properties or whether one should be 
> an extension of the other. That's a legitimate technical argument. 
> Over to you to sort it - but as a design principle, please don't have 
> the same property/class names in the two namespaces with different 
> semantics (ssn:Platform and sosa:Platform, for example). My instinct 
> is to prefer direct usage over sub classes but that's a generalist's view.
>
>     7. There is work going on concerning the SOSA-SSN alignment that 
> is being shared piecemeal, issue by issue. That is not right. Put it 
> on the wiki or GH, argue about it, edit it in front of everyone. The 
> idea of "we'll share it when it's finished" is not the way we should work.
>
>     8. There is a lot of unhappiness in the SSN group at the moment, 
> which is unfortunate and needs to be fixed before everyone walks away.
>
>     9. If the group so wishes, we can easily arrange a one off long telco.
>
>     Phil.
>
>     [1] 
> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0096.html
>
>     --
>
>     Phil Archer
>
>     Data Strategist, W3C
>
>     http://www.w3.org/
>
>     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