RE: issue-117: Comments on the SOSA and SSN implementations

Hi Raul,


> And, now, this comes to my mind. Since we are making significant changes to what we published as 1st Public Working Draft, do we need to publish a 2nd PWD? Has this been discussed/decided?

Now that one I can answer positively!  That is indeed what all the recent action has been about! We are well on  track to do this and it will be formally approved on Jan 4th assuming we all vote for it --- announcement on vote to come out around  today.

Actions tend to be smaller things --- and must  to be assigned to only one person --- not to the team as a whole. We could assign them to an arbitrary editor, I suppose, but that may have its own problems.

Issues are used
 (1) to mark things as unresolved/not yet done/ inside published documents (ie working drafts)
 (2) To bring them to the attention of the chair for agenda planning purposes.
 (3) To provide evidence that issues raised by participants or outsiders have been given due attention.

So yes, we have some issues that are simply placeholders for things to be discussed at the right time. That's ok. It does not make a commitment to do them (an action is more of a commitment to do it).

Indeed this relates to my recent dummy-spit about the haphazardness of the late stages of the working draft -- some very significant things went into the draft because someone put in a PR in the frozen state to get them in --- not because they had been agreed on in a meeting nor discussed in a list nor raised as an issue nor prioritised nor even consensually agreed. Only  because they put them in a PR at the last minute, and therefore our published Public Working Draft, and thereby automatically making them a top priority.

> On the other hand, we are opening plenty of issues but we are not closing them! Only 4 issues have been closed and in one month it will be the birthday of our first issue (issue-37).

Agreed --- but we have closed some. A lot more new ones went in the past week ... I do think issue-37 could be closed now. Issue-42 (second oldest)  could not be actioned until about now. Issue-44 (3rd oldest)  is done, I think (but is possibly still inserted  our WD so cannot be closed until our WD is out). Some of the very recent ones were about the WD and have been solved (but not closed) .  Etc. 

>With our current time constraints we really need to review the SSN issues (are they still relevant?), reduce them significantly (should some of them be postponed?), and prioritize them (e.g., issue-115 is key for much of the work that needs to be done).

Totally agree. Please propose prioritisation  to the chair (Armin, not me)  as a critical priority!

>Also note that the current 51 SSN issues make impractical to try to discuss them all in telcos, so we need to focus on the most important ones (prioritize again).

Totally agree.   For the prioritized ones ,  some can be simply resolved by assigning as actions to someone who can deliver on them as soon as we prioritise.

> According to Phil, by March we need to be into CR. So we have two months to finish with the specification.

Yes, totally agree.

Personally I am very keen to do monthly WDs from now until the CR state (so that's only 2?) , following a suggestion from Jeremy Tandy.  I have suggested this to the editorial team , but I have not seen any interest and I cannot do it on my own.

And personally I believe issue-115 --- interpreted rather more broadly --- ie "how do sosa and ssn cohabitate?"  -- is by far the top priority and the number one critical risk for the whole  spec.   And this is very strongly wrapped up in the "implementation" constraints --- hence my own hard push to get people thinking about implementation and my own appreciation for your start on that. We will  have no recommendation/standard without implementation evidence. 

And thankyou again for your own careful review and strong suggestions for the WD. 
-Kerry


-----Original Message-----
From: Raúl García Castro [mailto:rgarcia@fi.upm.es] 
Sent: Wednesday, 21 December 2016 5:45 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: issue-117: Comments on the SOSA and SSN implementations

Dear Kerry,

I have gone through my comments and created issues for all those things for which no issue was created yet, resulting in issue-118, issue-119, issues-120, issue-121, issue-122, and issue-123.

In this process, I've notice some issues (:D) in the issue tracker.

On the one hand, in some cases we are mixing actions with issues (e.g.,
ISSUE-55: Align ssn with rdf datacube). If it is an issue we should discuss whether we should make such alignment and if we decide to do so to create the corresponding action. If it is an action, then someone has just to put effort on that, no discussion needed.

On the other hand, we are opening plenty of issues but we are not closing them! Only 4 issues have been closed and in one month it will be the birthday of our first issue (issue-37).

With our current time constraints we really need to review the SSN issues (are they still relevant?), reduce them significantly (should some of them be postponed?), and prioritize them (e.g., issue-115 is key for much of the work that needs to be done).

Also note that the current 51 SSN issues make impractical to try to discuss them all in telcos, so we need to focus on the most important ones (prioritize again).

According to Phil, by March we need to be into CR. So we have two months to finish with the specification.

And, now, this comes to my mind. Since we are making significant changes to what we published as 1st Public Working Draft, do we need to publish a 2nd PWD? Has this been discussed/decided?

Kind regards,

El 20/12/16 a las 15:12, Kerry Taylor escribió:
> Raul --- there are many really important comments here. The SSN+SOSA one especially so. Thank you for raising it and the answer will not be straightforward.
>
> Can you please help us  give these issues  proper attention by putting them on the tracker  https://www.w3.org/2015/spatial/track/, one by one?
>
> You can use this page https://www.w3.org/2015/spatial/track/products/4  
> to 'create '  https://www.w3.org/2015/spatial/track/issues/new , And use the product pull-down to attach them to SSN product, and the raised-by  pull-down to attach your name to it.
>
> e.g I just did this one copied  below and you can see it here https://www.w3.org/2015/spatial/track/issues/117 along with an opinion I added to your issue.
> Better still, if you write issue-117 somewhere in an email (as I just did right then, and again in the subject line) , the email gets automatically filed against the issue --- so you should be able to see this very email  linked to issue-117 in the tracker as soon as I send it.
>
>> * dul:includesEvent
>> The dul:includesEvent property has dissapeared and the local restriction that relates an Observation to a Stimulus has dissapeared to.
>> Maybe it has been made in purpose, but the possibility of relating those two classes is not there anymore.
>
>
> Btw -- the sensordatasheet problem you note has the same provenance, 
> but possibly a different solution --Kerry
>
>
> -----Original Message-----
> From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
> Sent: Thursday, 15 December 2016 7:10 PM
> To: Raúl García Castro <rgarcia@fi.upm.es>; public-sdw-wg@w3.org
> Subject: RE: Comments on the SOSA and SSN implementations
>
> Hi Raul,
>
> There are many important issues raised in this one email. Would it be possible for you to raise them each as separate issues in the tracker , please, so that we can work through them systematically?
>
> For some, there is a closely related existing issue , in which case it would be ideal if your suggestions could be linked in there (just add a note to the issue, or re-send the relevant point to the public list, mentioning is issue somewhere , like  this as an example:
>
> * sosa:Platform issue-88
> (a) The documentation says "(including rdf:type rdfs:Class, owl:Class humans)", should this be "(including humans)"?
>
> (b) in SOSA a Sensor is hosted by a Platform, in SSN a SensingDevice (not a Sensor) is on a Platform.
>
> --Kerry
> -----Original Message-----
> From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
> Sent: Thursday, 15 December 2016 3:31 AM
> To: public-sdw-wg@w3.org
> Subject: Comments on the SOSA and SSN implementations
>
> Dear all,
>
> I've been reviewing the implementations of SOSA and SSN and here you have some comments (plus a couple of pull requests) on each of them and on the combination.
>
> SOSA
> ----
>
> * sosa:Platform
> The documentation says "(including rdf:type rdfs:Class, owl:Class humans)", should this be "(including humans)"?
>
> * sosa:Sample
>  From the documentation, a Sample is a FeatureOfInterest (shouldn't Sample be a subclass of FeatureOfInterest?). I also think that there is no need for a Sample class; I would just state that a FeatureOfInterest can have as a sample another FeatureOfInterest. In any case, unless some of these changes are made, the current model "does not allow" taking samples of samples.
>
> * sosa:hasValue
> Why not including meta:domainIncludes sosa:Result in this property?
>
> * Units of measurement
> Also, regarding values, I think that right now the ontology falls short on supporting how to describe them when they require a unit of measurement. Along the documentation plenty of examples are included that mention a unit of measurement (e.g., "20m") but in the documentation of sosa:hasValue it only appears "23 or true", without mentioning the unit anymore. Since sosa:hasValue is a datatype property, do we expect people to attach the unit of measurement to a sosa:Result?
>
> * sosa:hosts
> The documentation mentions a SamplingDevice that is not mentioned in the ontology.
>
> * sosa:madeObservation
> Why is the inverse observedBy property not defined?
>
> * sosa:phenomenonTime and sosa:resultTime I would remove these properties from SOSA, mainly because I think that they aim for a richer level of detail than the other concept descriptions in the ontology.
> Having them inside is no main problem, but then their definition is quite weird since one is defined as an object property and the other as a datatype property. I understand why they have been defined that way, but it is not elegant.
> On the one hand, in sosa:phenomenonTime we talk about time intervals and instants; we have here an opportunity to link to the W3C Time ontology, and even talk about TemporalEntities?
> On the other hand, in sosa:resultTime we talk about xsd:dateTime (being the only property in the ontology that specifies a rdfs:range); to be coherent we should talk about time instants.
>
> * Importing SKOS
> I would move the last triples defining the SOSA ontology to the beginning. Related to these, why do we need to import SKOS?
>
> SSN
> ---
>
> * ssn:startTime and ssn:endTime
> They are not documented in the ontology with rdfs:comment (it happens in others such as observedBy). And the link that appears in the description is "broken" (http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Base#Time).
> They are not used in any of the other entities in the ontology; should we remove them?
>
> * dul:includesEvent
> The dul:includesEvent property has dissapeared and the local restriction that relates an Observation to a Stimulus has dissapeared to.
> Maybe it has been made in purpose, but the possibility of relating those two classes is not there anymore.
>
> * ssn:SensorDataSheet
> This class is not related to other classes or properties in the model.
> Should we remove it or relate it?
>
> SSN+SOSA
> --------
>
> Taking the SSN ontology as it is (in GitHub) and SOSA, right now it cannot be said that one is a core module of the other, since:
>   -  SSN does not reuse SOSA vocabulary terms (this could be implemented by mappings)
>   - SOSA adds actuation and sampling
>   - SOSA renames plenty of classes and properties. In some cases maybe the intended meaning is more or less equivalent, but in others it radically changes (for example, ssn:hasValue is an object property and sosa:hasValue is a datatype property).
>   - The modelling decisions in both are different; for example, in SOSA a Sensor is hosted by a Platform, in SSN a SensingDevice (not a Sensor) is on a Platform.
>
> The result is that currently we don't have a clean view on the ontology as a whole as a composition of modules. And for anyone using the ontology it will be quite difficult to digest everything (e.g., there are 2 time-related properties in SOSA attached to an observation, in SSN there are another 2 attached to an observation and 2 that are not attached to anything.
>
> In other words, my opinion is that right now SOSA is something derived from SSN but we still have plenty of work to do (either changing SOSA, SSN, or both) to put them together so it can be considered a proper core module.
>
> If not, the risk is to produce two different (even if compatible) ontologies which is not desirable for interoperability.
>
> In other (now more positive) words, I think that SOSA is the result of a very good work, and I'd like it to be a proper core part of SSN.
> Let's see how we can do it!
>
> Kind regards,
>


-- 

Dr. Raúl García Castro
http://www.garcia-castro.com/


Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19

Received on Thursday, 22 December 2016 00:29:29 UTC