SSN / SOSA / Activity Hierarchy

[kjano]

The following is about the current state of SOSA after commits cd8b196 and e46914e.

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

[dr-shorthair]

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.

[KerryLea]

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

[arminhaller]

Please see comments inline.

From: Kerry Taylor notifications@github.com Reply-To: w3c/sdw reply@reply.github.com Date: Wednesday, 27 July 2016 11:36 am To: w3c/sdw sdw@noreply.github.com Subject: Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

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.

The proposed core as of now is just one file: https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl Please just ignore all other files there.

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

This was raised as an issue in an earlier email by Simon. It may be useful to distinguish Procedures (which were processes in SSN) from activities in a sub-class hierarchy, but there are different opinions on that. Personally, I am agnostic to include the superclasses or not in the core.

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?

As above, only the one file should be discussed at the moment.

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.

Schema annotations were only included for documentation purposes (for the group to understand the domain and range), they should NOT be in the core.

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?

Agree, I don’t think platform should be in the core.

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?

Agree, that was not in the initial core. Jano, what was your rational for that one?

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

Agree, I raised this earlier today. I don’t think we need Observing. Sensing should be enough. But there are different opionions on that one.

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?

Sounds good to me, but that undermines the premise that we should not rename SSN too much.

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

Agree, although users can use any other vocabulary for locations.

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?

As above, just there for documentation purposes at the moment.

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?

We did, I used the IoT-Lite for the proposal of the core on Webprotege and borrowed some object properties from IoT-lite.

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?

We all agree on that one, and I believe many were keen on discussing the proposal today in the call.

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

[dr-shorthair]

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

Agree, that was not in the initial core. Jano, what was your rational for that one?

The sampling classes were introduced by me. Sampling may not be a commonly recognised IoT requirement*, but it is ubiquitous in scientific observations (including social science), and is reflected in several of the Requirements in UCR. I was not aware that we were planning to limit the scope of the core to IoT. Sampling is a core feature from the precedent work in OGC.

The SOSA core file includes a set of subclasses related to observing, sensing, sampling, and actuation in each of the hierarchies headed by Device, Procedure and Activity, as well as classes for SamplingFeature and ObservedProperty - see the diagrams on the Wiki page https://www.w3.org/2015/spatial/wiki/SOSA_Ontology . This is a strawman, so we included more than we expect to survive, but enough so the symmetries in the class hierarchies are clear to begin with. The hierarchies might not be agreed by all, but it is always easier to argue around a concrete proposal, so we made one.

I agree that there might need to be a cull of the classes shown here (there are now 18 classes which is quite a lot), but if this does happen, then we must be clear about the rationale for what makes the cut and what doesn’t.

I also understand the resistance to subclassing, but I suggest it is helpful to distinguish between these top-level groupings (Device, Procedure and Activity) and can’t really see a better alternative.

Responsibility for what is currently there is as follows:

•    Armin developed SANDA with a little input from me

•    I forked SANDA and refactored it into SOSA, on a branch in github

•    Jano made some mods to SOSA

•    Jano pulled it to gh-pages to make it more visible to the WG

Ø And why are we taking no account of either WoT (W3C) or SensorThings (OGC)

SensorThings is aligned to O&M, but I agree it deserves a separate look to check if any key concepts are excluded.

Ø or our own use cases, or IoT-lite or ( barely ) ssn here?

I agree that the connection to the original SSN is getting more distant in this strawman – maybe there is a way to bring it back closer. “Tabula rasa” was the phrase used by Jano in today’s telecon, so I was just quoting.

Some class names have been changed for clarification. There has been a history of misunderstandings partly because some of the class names said different things to different readers – for example the word “Observation” itself is a topic of contention. That’s why I thought the diagrams on the Wiki page might help, including the Activity hierarchy (I swallowed hard before adding it, but it appears to have helped sharpen the conversation at least).

SOSA is a strawman, based on Jano’s proposal for horizontal and vertical modularization. I explained briefly on the Wiki page what I did so far in the vertical extensions, but this was mostly to explore and illustrate how Jano’s modularization might look in practice, and also to help understand what is common between the Sensor-Network, Observation and Sampling modules, and thus belongs in a core.

Simon

*on Sampling and IoT – I suspect if you look hard enough you will find that most IoT applications also involve sampling features, it is just that they are not called out in the stream coming from the device. Our work with many communities has revealed that many of the tangles in describing observations can be unscrambled by thinking a bit harder about the sampling strategy.

[kjano]

Agree, that was not in the initial core. Jano, what was your rational for that one?

IMHO, what we are doing right now is experimenting. We add classes and relations and remove others. The core question is whether we converge and I believe we do. Adding code to a public repository is an invitation, not paternalism. I personally believe that sampling is a core topic and that we need an anchor in SOSA-core for a separate sampling module. It also aligns very well with our definition of /Procedure/ (see the comment here: https://github.com/w3c/sdw/commit/cd8b19621b81677b0ab26d657009bcb4ef0616d0). I would suggest that we create a reduced version of what is in there now. I will work on this later tonight. If some of us believe that this reduced version is still be too much, we can remove sampling later on, but lets first make sure we have some actual proposal on the table (in terms of said reduced version).

Jano

[KerryLea]

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 w3c/sdw-sosa-ssn#58 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 cd8b196https://github.com/w3c/sdw/commit/cd8b19621b81677b0ab26d657009bcb4ef0616d0 and e46914ehttps://github.com/w3c/sdw/commit/e46914e3cad108a9334aa16de5c0120b5c06a173.

@dr-shorthairhttps://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 GitHubhttps://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the threadhttps://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-sosa-ssn/issues/58, 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

[KerryLea]

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 w3c/sdw-sosa-ssn#58 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 cd8b196https://github.com/w3c/sdw/commit/cd8b19621b81677b0ab26d657009bcb4ef0616d0 and e46914ehttps://github.com/w3c/sdw/commit/e46914e3cad108a9334aa16de5c0120b5c06a173.

@dr-shorthairhttps://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 GitHubhttps://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the threadhttps://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-sosa-ssn/issues/58, 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

[dr-shorthair]

Regarding "platform/device/observer" - I think the intention is that this is the system that hosts the things that implement the procedure. This could be (i) a platform like a phone or satellite or UAV or person that hosts a bunch of sensors that implement sensing procedures (ii) a computational system that hosts software which implements an algorithm to simulate or make forecasts.
(iii) a platform like a piece of earth-moving machinery, or a tug-boat, or a UAV that hosts a bunch of actuators that change the state of the world (iv) which also blends into platforms that host sampling devices that takes specimens or drill boreholes to enable subsequent observations. Host works for me.

Regarding "sensing/observing" - since it also includes interpreting, simulating and forecasting, I wonder if we should bite the bullet and use estimating for the general case?

Regarding 'samplingFeature' - I wonder if it should be renamed "Sample". It was called SamplingFeature in O&M originally for three reasons - (i) to be related to but distinct from (domain) Feature (ii) to be a noun rather than a verb (iii) to be more general than the physical specimen case, which was only one kind of sampling feature. But if we are pitching to a broader audience, then more common language would be a clear benefit.

[kjano]

Regarding 'samplingFeature' - I wonder if it should be renamed "Sample". It was called SamplingFeature in O&M originally for three reasons - (i) to be related to but distinct from (domain) Feature (ii) to be a noun rather than a verb (iii) to be more general than the physical specimen case, which was only one kind of sampling feature. But if we are pitching to a broader audience, then more common language would be a clear benefit.

Yes, Sample would work very well for me.

Host works for me.

Okay, so lets try Host (for all the good reasons you mentioned above). (see also https://github.com/w3c/sdw/pull/311#issuecomment-235801505)

Regarding "sensing/observing" - since it also includes interpreting, simulating and forecasting, I wonder if we should bite the bullet and use estimating for the general case?

I see your point but IMHO this would remove all the many crisp cases like observing a coin flip. To me it looks like observation is widely used and understood and we can make sure the comments we add are clear and inclusive.

I will update the code with your and Armin's suggestions (based on the version we prepared as a reaction to Kerry's suggestions).

[dr-shorthair]

Please review latest updates to my pull-request. It looks like a lot of changes, because the earlier request was not yet accepted, but was merged with current head immediately before my latest suggestions, which are:

• fixed one error (prefix meta: was missing a trailing "/") and
• tweaked the documentation, in particular asking some questions to clarify scope of 'Sensor'.

[kjano]

Done

[dr-shorthair]

@kjano - Somehow my additional comments on sosa:Sensor got dropped.

sosa-core:Sensor rdfs:comment "Does this also include (something) that implements an interpretation procedure?"^^xsd:string ; rdfs:comment "Does this also include software used to implement a simulation or forecasting procedure?"^^xsd:string ; .

I wonder if this happened because I used multiple rdfs:comment properties?

[kjano]

Sorry for the confusion. I addressed them in my commit message and removed them. See: https://github.com/w3c/sdw/commit/5764c89433f0a32115ee657318a26fbd4c3acc64

[dr-shorthair]

"Does this also include (something) that implements an interpretation procedure?" If this is about anything involving cognition, I would say no.

Yes - that was what I had in mind. The kind of case I'm thinking of is geological interpretation, expressed as a geological map. It is underlain by multiple sensory inputs, but mediated by a cognitive process. The relationship between activity-of-estimating, agent, procedure and result is similar to sensor observations, but the word 'sensor' is a stretch. If this is out of scope, then it suggests that there is a common superclass.

[dr-shorthair]

Documentation of 'Host' should be supplemented with some words to indicate that it can also be a computing system, which hosts software implementations.

[kjano]

Very true.

On 08/01/2016 10:09 PM, Simon Cox wrote:

Documentation of 'Host' should be supplemented with some words to indicate that it can also be a computing system, which hosts software implementations.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrH9iPj-Lg4ZMEe63DD8n4mbTNDXZXAks5qbtEbgaJpZM4JVlJq.

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

[kjano]

Done: 7e71a20

rdfs:comment "A device, (computational) system, platform, or agent (including humans). A host carries at least one Sensor, Actuator, or sampling device to produce observations, actuations, or samples, by following a Procedure. In case of virtual sensors, a host can be a computing system which hosts software implementations, e.g., simulations."@en ;

[arminhaller]

Apologies for my silence, teaching duties are taking over my life atm. Just got nudged by Simon to comment on the proposal. Looks all good to me. The only thing I feel strongly about is the "Host". I don't like the name, but more importantly, I believe we should distinguish in the core between an Observer (Human) and a Platform (I gave up on the Device name), the tangible thing. The Observer, e.g. a Policeman makes an Observation based on a cognitive process that a car is driving more than 100 kph, but his colleague standing next to him uses a handheld radar device (device is so much more intuitive, isn't it ;-)) that is a platform that hosts a sensor that implements the sensing of the speed of the object to measure it accurately at 113kph.

[lieberjosh]

Terminology — the bane of existence.

What if we defined another feature type? After all, we are trying to describe something that exists at times and places in the world and facilitates sensing there. How about SensingFeature to go with SamplingFeature and FeatureOfInterest? It would also in a way complete the list of features that Things as in Internet of Things may be referring to. It corresponds to the role of Platform, which is to gather the locations and perspectives of collocated sensors. Platform, Analyzer, and Observer could then be subclasses of SensingFeature to help distinguish between use of devices, computations, and organs, I suppose.

Josh

On Aug 2, 2016, at 2:11 AM, Armin Haller notifications@github.com wrote:

Apologies for my silence, teaching duties are taking over my life atm. Just got nudged by Simon to comment on the proposal. Looks all good to me. The only thing I feel strongly about is the "Host". I don't like the name, but more importantly, I believe we should distinguish in the core between an Observer (Human) and a Platform (I gave up on the Device name), the tangible thing. The Observer, e.g. a Policeman makes an Observation based on a cognitive process that a car is driving more than 100 kph, but his colleague standing next to him uses a handheld radar device (device is so much more intuitive, isn't it ;-)) that is a platform that hosts a sensor that implements the sensing of the speed of the object to measure it accurately at 113kph.

— 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-sosa-ssn/issues/58, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhpIT-nl1FMyzUqtAdmORSwMgWFxaks5qbt94gaJpZM4JVlJq.

[kjano]

We are running in circles. I will open a new issue for this.

Btw, SamplingFeature is now called sample.

[kjano]

Okay, I tried to summarize the discussion in a new issue here https://github.com/w3c/sdw-sosa-ssn/issues/61 to make it easier for for everybody to follow. Looking forward to your thoughts.

[KerryLea]

I wonder whether these “circles” could be circumscribed by some clear statements about what a “core” is supposed to be? I, for one, admit to being confused about this (as I have said before).

Here’s a (partially inconsistent) strawman :

The SSN core comprises (conjunctively): -1 A vocabulary that is expressed in rdf/rdfs but is also in OWL-DL -2 A vocabulary that comprises only terms for IoT applications observing data from low energy, low memory devices

• 3 A vocabulary that eschews rdfs:domain and rdfs:range and rdfs:subClassOf
• 4 A vocabulary that is aligned with the other deliverables of the SDW -5 A vocabulary that comprises only terms (properties and classes) that are essential, i.e. every use case (of the SDW UCR) would need to use all of the terms
  • 6 A vocabulary that is contained in one file and does not owl:import

And given that (as I understand the intention, quite possibly incorrectly at this time ) the “core” is strongly tied to the “modularisation” goal, perhaps a top-down approach might work better – ie start with ssn and pull it apart (and recall we already have a proposal on the table for that we can work from –see charter) .

I am afraid that I have been unable to contribute much to this progress to date (other masters) but I plan to go back to ssn and have a go at a top-down approach before the F2F (and making corrections as I have observed to the version of the FPWD, following, to the extent it seems workable, the vertical/horizontal modularisation style https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Proposal_5_made_by_KJanowicz . I am not certain what a “core” would look like following this approach, but I am certain it would not meet 2 above as it would be missing some things: Actuation, for example.

-Kerry

From: kjano [mailto:notifications@github.com] Sent: Wednesday, 3 August 2016 3:24 AM To: w3c/sdw sdw@noreply.github.com Cc: Kerry Taylor kerry.taylor@anu.edu.au; Comment comment@noreply.github.com Subject: Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

We are running in circles. I will open a new issue for this.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APzSnYlDnSGRsQqdvuTKN7B2akYSdOhBks5qb30wgaJpZM4JVlJq.

[kjano]

Hi Kerry,

I wonder whether these “circles” could be circumscribed by some clear statements about what a “core” is supposed to be? I, for one, admit to being confused about this (as I have said before).

Sure. I will try to clarify the question you raised below.

-1 A vocabulary that is expressed in rdf/rdfs but is also in OWL-DL

We have discussed this in our telcons and also per email/issue tracker several times. The point is to have a surface semantics for SOSA-core that uses a reduced and intuitively to understand fragment of Web-based knowledge representation languages. Whether these fragments are from RDF(S) or OWL does not really play a role as long as we can assume that a typical Web-developer understands what is being axiomatized.

-2 A vocabulary that comprises only terms for IoT applications observing data from low energy, low memory devices

I do not believe that SOSA-core should be as restrictive. This would also make it hard to broaden it again in the other modules. To the contrary, SOSA-core should be the common set of axioms required for a wide range of applications. IoT is, as discussed in the last telcon, an example.

• 3 A vocabulary that eschews rdfs:domain and rdfs:range and rdfs:subClassOf

We use the schema.org versions domainIncludes and rangeIncludes so far. As we discussed some months ago on the W3C list, we would like to avoid using global domain and range restrictions. So far we do not use rdfs:subClassOf in SOSA-Core, but we could do so.

• 4 A vocabulary that is aligned with the other deliverables of the SDW

Yes, we are trying to do this.

-5 A vocabulary that comprises only terms (properties and classes) that are essential, i.e. every use case (of the SDW UCR) would need to use all of the terms.

I am not sure what this means. SOSA-Core sits somewhere between the old SSO and SSN. It is a common core for further SDW SSN modules but also useful and applicable on its own. In fact, I think it is already in pretty good shape for exactly this task.

• 6 A vocabulary that is contained in one file and does not owl:import

I think we have this for SOSA-core right now (leaving our the schema.org part).

I am not certain what a “core” would look like following this approach, but I am certain it would not meet 2 above as it would be missing some things: Actuation, for example.

There is some good news here Kerry. Actuation is already part of SOSA-Core; see https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl . We have been implementing many change requests over the past weeks.

but I plan to go back to ssn and have a go at a top-down approach before the F2F

I am not entirely sure what that means but it sounds a bit contra-productive. Why don't you just have a look at the current SOSA-core version and the outstanding issues and help to get it wrapped up. I think we should be very positive about the current progress. Given that we need to have something ready very soon (as you reminded us), we seem to be rapidly approaching a first complete version of SOSA-Sore.

Cheers, Krzysztof

[dr-shorthair]

2 A vocabulary that comprises only terms for IoT applications observing data from low energy, low memory devices

That was definitely not my understanding or expectation. I think the current proposition is that the core should be a basis for any sensing/observing/sampling/actuating application. My preference therefore is to focus on the necessary superclasses, but with a few recognisable specializations.

3 A vocabulary that eschews rdfs:domain and rdfs:range and rdfs:subClassOf

Sub-classing seems to be to be too useful to reject completely. Particularly in view of my comment above. So regarding the use of particular KR subsets, I'm not sure that we can usefully restrict it this way:

1 A vocabulary that is expressed in rdf/rdfs but is also in OWL-DL

We should certainly minimize our use of the more esoteric constructions. But where it is useful for documentation, and does no harm (as far as we can tell) in terms of entailments, then we should use elements from the existing KR vocabularies.

And given that (as I understand the intention, quite possibly incorrectly at this time ) the “core” is strongly tied to the “modularisation” goal, perhaps a top-down approach might work better – ie start with ssn and pull it apart

... except that we already know that SSN has some gaps - e.g. sampling.

[kjano]

Okay, I admit that it took me a long time to reply to your question :-). I Think your were right and that the class of observations should also include cases that require (and thus involve) complex cognitive processing.

On 08/01/2016 10:08 PM, Simon Cox wrote:

    "Does this also include (something) that implements an
    interpretation procedure?"
    If this is about anything involving cognition, I would say no.

Yes - that was what I had in mind. The kind of case I'm thinking of is geological interpretation, expressed as a geological map. It is underlain by multiple sensory inputs, but mediated by a cognitive process. The relationship between activity-of-estimating, agent, procedure and result is similar to sensor observations, but the word 'sensor' is a stretch. If this is out of scope, then it suggests that there is a common superclass.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrH9kSmRmuCxfcqT7_ehT_zK5_WVdgtks5qbtDKgaJpZM4JVlJq.

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

[KerryLea]

I note that this message came specifically to me in cc but I can’t make any sense of it. Perhaps it was an accident. If it was substantive ssn discussion then please post to public-sdw-wg@w3.orgmailto:public-sdw-wg@w3.org. See https://www.w3.org/2016/08/23-sdwssn-minutes#item03 and earlier ssn and sdw meetings for this policy.

--Kerry

From: kjano [mailto:notifications@github.com] Sent: Wednesday, 28 September 2016 6:50 AM To: w3c/sdw sdw@noreply.github.com Cc: Kerry Taylor kerry.taylor@anu.edu.au; Comment comment@noreply.github.com Subject: Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

Okay, I admit that it took me a long time to reply to your question :-). I Think your were right and that the class of observations should also include cases that require (and thus involve) complex cognitive processing.

On 08/01/2016 10:08 PM, Simon Cox wrote:

"Does this also include (something) that implements an interpretation procedure?" If this is about anything involving cognition, I would say no.

Yes - that was what I had in mind. The kind of case I'm thinking of is geological interpretation, expressed as a geological map. It is underlain by multiple sensory inputs, but mediated by a cognitive process. The relationship between activity-of-estimating, agent, procedure and result is similar to sensor observations, but the word 'sensor' is a stretch. If this is out of scope, then it suggests that there is a common superclass.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrH9kSmRmuCxfcqT7_ehT_zK5_WVdgtks5qbtDKgaJpZM4JVlJq.

Krzysztof Janowicz

Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edumailto:jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/w3c/sdw-sosa-ssn/issues/58, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APzSndrr7miynegIs5lNI9lh0WfPDJOzks5quYFpgaJpZM4JVlJq.