W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

FW: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Wed, 27 Jul 2016 02:11:46 +0000
To: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <PS1PR06MB1740BC96BFD8B79202998F8FA40F0@PS1PR06MB1740.apcprd06.prod.outlook.com>

From: Armin Haller [mailto:notifications@github.com]
Sent: Wednesday, 27 July 2016 12:00 PM
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)

Please see comments inline.

From: Kerry Taylor <notifications@github.com<mailto:notifications@github.com>>
Reply-To: w3c/sdw <reply@reply.github.com<mailto:reply@reply.github.com>>
Date: Wednesday, 27 July 2016 11:36 am
To: w3c/sdw <sdw@noreply.github.com<mailto: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.

From: Simon Cox [mailto:notifications@github.com]
Sent: Wednesday, 27 July 2016 7:54 AM
To: w3c/sdw <sdw@noreply.github.com<mailto: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<mailto:sdw@noreply.github.com%3cmailto:sdw@noreply.github.com>>>
Cc: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au%3cmailto:Simon.Cox@csiro.au>>>; Mention <mention@noreply.github.com<mailto:mention@noreply.github.com<mailto:mention@noreply.github.com%3cmailto: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>.

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-235456652>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEt3MAlVdrWrYVcq-xbYZabigHz5w2nHks5qZrY7gaJpZM4JVlJq>.

You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/w3c/sdw/issues/309#issuecomment-235459910>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APzSnfiiisE0fuYgrbXBaF-gizA9vv4Kks5qZruSgaJpZM4JVlJq>.
Received on Wednesday, 27 July 2016 02:12:14 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:23 UTC