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.

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.

From: Simon Cox []
Sent: Wednesday, 27 July 2016 7:54 AM
To: w3c/sdw <>
Subject: Re: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

I introduced the Activity hierarchy primarily so I could generate the diagram on 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 []
Sent: Wednesday, 27 July 2016 6:57 AM
To: w3c/sdw <<>>
Cc: Cox, Simon (L&W, Clayton) <<>>; Mention <<>>
Subject: [w3c/sdw] SSN / SOSA / Activity Hierarchy (#309)

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 ( 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<>, or mute the thread<>.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<>, or mute the thread<>.

Received on Wednesday, 27 July 2016 01:37:17 UTC