Re: UCR ACTION-111: new SSN requirements?

Hi Frans,

Re 1: I recognize that requirements should be abstract, but this one sounds all-encompassing. Also, it seems contrary to what we are currently trying to do in SSN, removing for example, the reliance on DOLCE Ultralite. What are open-ended elements of SSN? Upper level concepts?

Re 2: That seems to be an important requirement. Looking at what the WoT IG is currently doing in their semantic metadata descriptions for WoT devices http://w3c.github.io/wot/current-practices/wot-practices.html#semantic-metadata suggests that we need to consider, for example, the IOPE’s of actuators in some of our vertical modules of the ontology. We currently consider including already an Actuator class in the core.

Greetings,
Armin

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wednesday, 17 August 2016 8:48 pm
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: UCR ACTION-111: new SSN requirements?
Resent-From: <public-sdw-wg@w3.org>
Resent-Date: Wednesday, 17 August 2016 8:48 pm

Hello,

This thread is for discussing the need to describe additional requirements for the SSN deliverable in the UC&R document, based on the use cases that underpinned the original SSN specification. To investigate this topic, ACTION-111<https://www.w3.org/2015/spatial/track/actions/111> was started.

Kerry has made an analysis of the original use cases. A summary of that analysis can be read here<https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Summary_wrt_UCRs_for_SSN>. Two new requirements are suggested (copying from the wiki):

  1.  Review the extent to which domain-specific or open-ended elements of SSN should be extended, possibly by reference to external ontologies (skos-like vocabularies) as exemplars, or by small additional components.
  2.  Model tasking, programming and actuation of sensing devices.
If we (particularly the members active in the SSN subgroup) think these are valid requirements, then they need to be incorporated in the UC&R document somehow, which means that use cases from which they derive should be there (such a use case could be copied from the original SSN use case, or it could already exist in the UC&R document), and the requirements should be phrased as requirements (e.g. "It should be possible to....").

Please post your thoughts and suggestions! This subject will probably be discussed in the next SSN teleconference, it would be good to have implementable proposals by that time.

Greetings,
Frans