Re: State of SSN

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

Yes, absolutely. SOSA is something that we hope will generate a lot of 
uptake for Web developers, citizen science, smart sensors, and many 
other lightweight application areas. This is why it is so important to 
strike the balance between ease of use and compatibility to more complex 
models such as the full (new) SSN. SSN axioms provide a stronger 
axiomatization and also add many more details, e.g., new classes such as 
Deployment, that are required for SSN use cases but would be out of 
scope for the SOSA audience. I still believe that this is a great idea 
and it will need our joint effort to make this a success.

Jano



On 01/25/2017 04:28 AM, 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
>


-- 
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 Thursday, 26 January 2017 05:11:05 UTC