SSN / SOSA-core / Implementing the changes discussed yesterday (#311)

The new (proposed) version of SOSA-core including the changes requested 
by Kerry and others: 
https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl

The following is copied from https://github.com/w3c/sdw/pull/311:

I went into more details what a Procedure is and what it can be used for.

I removed all subclasses of Activity (such as Actuation) but not 
Activity itself. The description of Activity now names the previous 
subclasses as examples, e.g., a sampling activity. I changed all the 
comments that referred to these classes while making sure that the 
descriptions clarify that different procedures can be set up for 
different activities. Summing up, we have something like a soft 
hierarchy now, i.e., no axiomatization but natural descriptions for 
which kinds of activities and procedures can exist/ be useful.

I removed the strong link between Observation and Activity. We have to 
agree first whether an Observation is an Information Object or not. This 
is basically reverting the changes to the original SSN view without 
implying that this is the right way to go.

I removed Device and Platform but left Observer. Before somebody panics, 
there is actually a good reason for doing so based on yesterday's 
emails. We discussed before that we need something like SensingDevice 
for the thing that carries one or multiple sensors. We also discussed 
that this should not be Device because humans are not devices. We also 
discussed that the term Platform is often used in a different sense. To 
do so, I had to change the textual definition of Observer a bit. I 
suggest using mereotopology instead of class hierarchies here, i.e., a 
Sensor is mounted on (partOf, hostedBy,..) an Observer, but a Sensor is 
not a specific kind of Observer.I also removed all hierarchical 
relations that relate other classes to Device. As always, these are just 
proposals, nothing is set in stone. You will see later on that not 
having a common class for Actuators and Sensors is not perfect, but we 
can leave it like this for our initial discussion.

I left SamplingFeature in SOSA-core. Please read the initial 
rdfs:comment. IMHO, it makes a very strong and compelling case.

I left domainIncludes and rangeIncludes but changed the namespace to 
meta. Thanks Kerry for pointing this out.

I removed some statements that (IMHO) do not carry any semantics such as 
' meta:rangeIncludes owl:Thing ;' or 'rdfs:subClassOf owl:Thing ;'.

I removed some relations that we cannot use without subclasses of 
Procedure or Activity. One example is the samplingStrategy relation. I 
am not saying that this is the right path to take but simply do so to 
reflect yesterday's discussion.

Overall, the implemented changes reduce SOSA-core to 9 classes and 11 
relations (those will need more work in another commit).

Jano


On 07/26/2016 11:24 PM, Krzysztof Janowicz wrote:
> 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


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