Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309) --> Kerry's change requests

Hi Kerry, all,

> All, PLEASE keep this discussion on the public list , and by this 
> copying this trail  to the public list.

Absolutely, but we should follow activities on Github and the wiki as well.

> I have lots of problems with SOSA – many of which have been expressed 
> somehow already, but all of which seem to be in the version just 
> pushed to gh-pages during the meeting today.

This is very good news. Without having an implemented version out there 
for discussion, we would not be able to identify problems and address 
them together.

> 1)I see no need at all for an Activity hierarchy – it is new and it 
> has no purpose in the core (if I understand what a core is for – and I 
> **really** think we need to have a clear understanding of that to get 
> us on the same page).

See #309 on Github, I have the same feeling about the hierarchy and 
would propose to move it somewhere else for now. IMHO, the interesting 
issue Simon is raising is whether we need 'Activity' as a class in core 
or even within the entire SSN. If we do, then it is for the sake of 
structuring and this is what the figure in the Wiki is supposed to show: 
https://www.w3.org/2015/spatial/wiki/SOSA_Ontology. There is an 
interesting detail hidden in the last paragraph: observing and sensing 
generate results while actuating generates a state change. This is a bit 
too subtle for SOSA-core but it gives us an interesting starting point 
for an axiomatization in a later module using existential quantification 
in OWL. IMHO, this is really important as without DUL, we need to be 
extra careful that the classes we introduce carry meaning beyond their 
class label.

> 2) Indeed, I would go so far as to suggest that no subclassing should 
> be done in the core – just declaration of classes and properties 
> (extending further from the previous reasoning about domains and 
> ranges). Let’s think of this as a “vocabulary” in the weakest sense?

I had the same feeling; see my other email '[In RDFS] we cannot state 
that classes are disjoint nor that their *interpretations* are /proper/ 
subsets.  This means that in this particular case we have not really 
said anything'. I am not really sure whether this just means no 
'Activity' hierarchy or no hierarchies at all in core. Certainly 
something we should discuss. The subclassing of 'Procedure' may be 
something worth keeping. Opinions?

> 3)I do not understand why so many files are needed for the “core” for 
> small devices (if that is what the core is? ). I would have thought 
> the rdf core should comprise exactly one file --- why so many for the 
> “simplest” part of ssn? What use case does that serve? Or are all the 
> files that have been pushed all kinds of things that are not “core”? 
> In which case what happened to the “let’s focus on the core alone “ 
> line  this morning?  Is the “core” just sosa-core? In which case 
> what’s  those other files meant to be?

The other files are just putting our work in relation to existing 
approaches. *Super* important, but not key for now. Feel free to ignore 
them and just look at sosa.ttl.

> 4)I don’t see any case for having those dc and schema annotations in 
> the core  -- the schema has also been questioned before. We need to 
> think hard about what someone is going to do with this core  vocab.
>

I see your point. Still, I would suggest to leave them there for now. 
They do not carry any formal semantics but potentially make a huge 
difference in how the ontology can be used by practitioners and how our 
work can be searched in ontology repositories. Some of this will also 
act as useful metadata for many other use cases.

> 6)I don’t accept that “sampling” is any business of IoT , and 
> therefore should not go in the core. And now we have “sampling 
> devices” too? Why? Probably a good concept for the highg end 
> –all-of-ssn  horizontal case, but in the core?

As argued in another mail, sampling is key for so many issues including 
procedures. I agree that we may have too much sampling details in core 
right now, but we should probably have at least an anchor in their for 
the sampling module we already discussed some weeks ago in a telcon. 
Sampling is also a key *bridge* to the OGC community and we need their 
buy-in.

> 8)As noted below “observation” in ssn is a record of an observation, 
> and differs considerably from “observing” as a renamed term as 
>  currently proposed.  I think there is a very good case for removing 
> both “observation” and “observing” from the core Why does it have to 
> be there?.

We need one of them. Observation was also at the core of SSN and SSO. 
The issue here is that Observation and Observing are probably the most 
difficult concepts we have to deal with and O&M seems also to struggle 
with them. I think we have a real opportunity here to get it right this 
time. Personally, I could not imagine SSN/SOSA without the concept of an 
Observation. How would you talk about Results, ObservedProperties, and 
so forth?

> 9)I wonder why a  “used_procedure” or anything that refers to the 
> sensing method belongs in the core.  Is this so critical that it needs 
> to complicate the core? Again – what does define what shoud go in the 
> core?

For reasons of reproducibility. See 1-4 here: 
https://github.com/w3c/sdw/commit/cd8b19621b81677b0ab26d657009bcb4ef0616d0 
(which is copied from an older discussion on the sdw mailinglist).

> 10)It has been proposed in the group (maybe Sefki?)  that 
> “featureOfInterest” confuses Iot users.  I agree, while this **is** 
> the ssn term  and does have the OGC heritage. I would rename to 
> something else  say, “sensedThing” which would be a subclass of 
> featureOfInterest outside the core. And we need to think about what 
> happens when an Iot  sensing device  does not even know what its 
> featureOfInterest is…what does it do?

I am certainly open for discussion but would strongly suggest to keep 
FeatureOfInterest. The IoT device either knows the FeatureOfInterest or 
the *SamplingFeature*. In most cases, I assume, it know the 
SamplingFeature. This is one of the many reasons why sampling really 
*does* matter for core. We have a nice example here: 
https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl (see the 
rdfs:comment on sosa-core:SamplingFeature).

> 11)I think (a simplified notion of )  “location”  needs to go in the 
> core – Iot devices are often mobile and GPS-enabled.

Interesting point. Not sure whether this is not already covered by 
declaring the FoI to be a Feature on the OGC sense. Josh, Simon?

> 12)schema:domainIncludes is wrong – it is “meta:domainIncludes”  and I 
> am not sure it does not get us into trouble anyway. I wonder (as has 
> been said  (jano?) ) whether we want it at all or whether it could be 
> more elegantly declared  as an annotation property in our context? 

Personally, I change my mind about this every day :-). I understand why 
it is included in schema.org but it appears to me that this is a 
shortcut for modeling the notion of /Affordances/ and without a clear 
interpretation it may do more harm than good. I really don't know...  
Should  we ask Dan Brickley?

> 13)And lots more…

After reading your email, I am pretty sure that we are all converging 
rapidly and that we can indeed have a first draft of SOSA-core within a 
few weeks.

Cheers,
Jano

P.s. I have to call it a night now.


On 07/26/2016 06:36 PM, Kerry Taylor wrote:
>
> All, PLEASE keep this discussion on the public list , and by this 
> copying this trail  to the public list.
>
> I have lots of problems with SOSA – many of which have been expressed 
> somehow already, but all of which seem to be in the version just 
> pushed to gh-pages during the meeting today.
>
> 1)I see no need at all for an Activity hierarchy – it is new and it 
> has no purpose in the core (if I understand what a core is for – and I 
> **really** think we need to have a clear understanding of that to get 
> us on the same page).
>
> 2) Indeed, I would go so far as to suggest that no subclassing should 
> be done in the core – just declaration of classes and properties 
> (extending further from the previous reasoning about domains and 
> ranges). Let’s think of this as a “vocabulary” in the weakest sense?
>
> 3)I do not understand why so many files are needed for the “core” for 
> small devices (if that is what the core is? ). I would have thought 
> the rdf core should comprise exactly one file --- why so many for the 
> “simplest” part of ssn? What use case does that serve? Or are all the 
> files that have been pushed all kinds of things that are not “core”? 
> In which case what happened to the “let’s focus on the core alone “ 
> line  this morning?  Is the “core” just sosa-core? In which case 
> what’s  those other files meant to be?
>
> 4)I don’t see any case for having those dc and schema annotations in 
> the core  -- the schema has also been questioned before. We need to 
> think hard about what someone is going to do with this core  vocab.
>
> 5)I don’t understand why Platform is in the core, and the relationship 
> of Platforms and Devices bears no resemblance to ssn at all. Why this 
> model?
>
> 6)I don’t accept that “sampling” is any business of IoT , and 
> therefore should not go in the core. And now we have “sampling 
> devices” too? Why? Probably a good concept for the highg end 
> –all-of-ssn  horizontal case, but in the core?
>
> 7)I agree that “Activity” does not belong in the core
>
> 8)As noted below “observation” in ssn is a record of an observation, 
> and differs considerably from “observing” as a renamed term as 
>  currently proposed.  I think there is a very good case for removing 
> both “observation” and “observing” from the core Why does it have to 
> be there?.
>
> 9)I wonder why a  “used_procedure” or anything that refers to the 
> sensing method belongs in the core.  Is this so critical that it needs 
> to complicate the core? Again – what does define what shoud go in the 
> core?
>
> 10)It has been proposed in the group (maybe Sefki?)  that 
> “featureOfInterest” confuses Iot users.  I agree, while this **is** 
> the ssn term  and does have the OGC heritage. I would rename to 
> something else  say, “sensedThing” which would be a subclass of 
> featureOfInterest outside the core. And we need to think about what 
> happens when an Iot  sensing device  does not even know what its 
> featureOfInterest is…what does it do?
>
> 11)I think (a simplified notion of )  “location”  needs to go in the 
> core – Iot devices are often mobile and GPS-enabled.
>
> 12)schema:domainIncludes is wrong – it is “meta:domainIncludes”  and I 
> am not sure it does not get us into trouble anyway. I wonder (as has 
> been said  (jano?) ) whether we want it at all or whether it could be 
> more elegantly declared  as an annotation property in our context?
>
> 13)And lots more…
>
> And why are we taking  no account of either WoT (W3C) or SensorThings 
> (OGC) or our own use cases, or IoT-lite or ( barely ) ssn here?
>
> Looking forward to a discussion in the next ssn meeting.  I would be 
> much happier to see the sosa core as a careful and deliberate 
> extraction of terms from ssn, with new ones as we think appropriate, 
> but certainly not an arbitrary introduction of similarly-named terms 
> that existed before, or new names for old things,  or old names used 
> in new ways… all of which seem to be happening here without any good 
> reason as far as I can see. Am I alone in that view?
>
> Fundamentally – it is clear to me that we need to jointly understand 
> better what a “core” is  well enough to understand what goes in it.
>
> --Kerry
>
> *From:*Simon Cox [mailto:notifications@github.com]
> *Sent:* Wednesday, 27 July 2016 7:54 AM
> *To:* w3c/sdw <sdw@noreply.github.com>
> *Subject:* Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)
>
> I introduced the Activity hierarchy primarily so I could generate the 
> diagram on https://www.w3.org/2015/spatial/wiki/SOSA_Ontology I agree 
> that it opens a set of issues that we might not want to tackle here, 
> with attendant risks. Though it also supports the explanation of the 
> difference between the procedures and activities, etc. There is 
> certainly a decision required about scope here.
>
> Your comment on Observing vs Observation:
> I guess this is a key tension with the use of the term Observation in 
> OGC context (which we have been discussing on and off for years now).
>
> If I understand correctly, your ‘Observation’ is a record of an 
> observation (an ‘information resource’).
> In OGC we had used ‘Observation’ for the event/activity in the world 
> (a ‘non-information resource’), and saw the record as a 
> ‘representation’ or ‘description’ of the event.
> But my level of skill in logic/ontologies may not be up to the rigour 
> you are using here.
>
> From: kjano [mailto:notifications@github.com]
> Sent: Wednesday, 27 July 2016 6:57 AM
> To: w3c/sdw <sdw@noreply.github.com <mailto:sdw@noreply.github.com>>
> Cc: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au 
> <mailto:Simon.Cox@csiro.au>>; Mention <mention@noreply.github.com 
> <mailto:mention@noreply.github.com>>
> Subject: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)
>
>
> The following is about the current state of SOSA after commits 
> cd8b196<https://github.com/w3c/sdw/commit/cd8b19621b81677b0ab26d657009bcb4ef0616d0> 
> and 
> e46914e<https://github.com/w3c/sdw/commit/e46914e3cad108a9334aa16de5c0120b5c06a173>. 
>
>
> @dr-shorthair<https://github.com/dr-shorthair>: I like and (mostly) 
> agree on the Activity hierarchy 
> (https://www.w3.org/2015/spatial/wiki/File:Activity.png). I am unsure 
> whether we really need this in SOSA-core and whether this does not end 
> up in yet another discussion of what activities, events, and processes 
> are, but I will not fight it. Are we clear about how sensing differs 
> from observing? If so, and if we want to keep this distinction, IMHO 
> we should rename Observation into Observing. An Observation is the 
> result of the activity of Observing something. This is not to say that 
> an Observation isn't an event but it is not an activity. Again, not 
> sure whether we really need this, but if we do, we should care about 
> these details. What do you think?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on 
> GitHub<https://github.com/w3c/sdw/issues/309>, or mute the 
> thread<https://github.com/notifications/unsubscribe-auth/AAlIL5yxPirrUcAtIMoaUdzORplVq3SGks5qZnStgaJpZM4JVlJq>. 
>
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/w3c/sdw/issues/309#issuecomment-235417507>, or 
> mute the thread 
> <https://github.com/notifications/unsubscribe-auth/APzSnSKo6I0oSGYM45umHo-w13bo6Hjbks5qZoHegaJpZM4JVlJq>.
>


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