Update sosa.ttl #311
Update sosa.ttl #311
Conversation
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).
|
Thanks Jano! I have two major concerns with removing so many classes/relations from the core. I believe we need the Actuation and Sensing Activity and in fact, I believe they are much more important in the core than the, in my opinion, too generic Activity class. The ontology should be specific to Sensing, Observing, (Sampling) and Actuating and we should give the user these classes for modelling. Also, I am a strong advocate of the SensingDevice class in the core. I believe it is of great importance to be able to say something about the device itself, i.e. the Apple iPhone or Samsung Galaxy and these devices include several Sensors. I will submit a separate version to my branch as I don’t want to overwrite your changes. But I strongly feel we need a bit more in the core than we arrived at now with this compromise. Cheers, From: kjano notifications@github.com 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). You can view, comment on, or merge this pull request online at: Commit Summary
File Changes
Patch Links: — |
|
Hi Armin,
Sure. I did this so we have a proposal on the table for the next round
I see your point but then Observation becomes an Activity too and as we
Yes, but the S really stands for Sensor. Maybe we should rename the
Yes, but this is not lost. It is called the Observer. The problem with
Great, thanks. Looking forward to seeing your changes and to pushing Jano On 07/27/2016 04:24 PM, Armin Haller wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu |
|
Ø Also, I am a strong advocate of the SensingDevice class in the core. I believe it is of great importance to be able to say something about the device itself, i.e. the Apple iPhone or Samsung Galaxy and these devices include several Sensors. I guess this is related to Jano’s comments on mereotopology vs subclassing. In the case of a device like a phone with several sensors, then it could also be thought of as a platform, which I think Jano calls an observer. Let me clarify the basis for the three hierarchies that I proposed in SOSA core –
I think you guys maybe prefer a different primary organization, maybe more functionally based? Can you explain what that is? |
|
Hi Simon,
Yes, see my other email sent 10min ago. The term Observer is more In fact, confusing mereotopology (or partonomy) and subsumption is a
This makes all sensors devices and thereby excludes humans and simulations.
Same here.
Agreed. Question is: is the class Observation really an action? Cheers, On 07/27/2016 04:49 PM, Simon Cox wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu |
(!) I know this best from Geology, where primitive observations on outcrops, boreholes, cross-sections, various machines that go ‘ping’ etc are combined by a skilled and experienced operator through an incompletely described process into an ‘interpretation’. The interpretation (e.g. a map) has much higher semantic value in terms of geological story-telling than the original observations, but everyone still recognizes that it is an imprecise and inaccurate estimate of the true state of the world. |
|
Hi Simon, I see your point. I am fine with changing Observer to Platform as long
This is something that I would really, really hope we can avoid. Most Best, On 07/27/2016 05:22 PM, Simon Cox wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu |
|
Ø > 2. Furthermore, I’m also quite happy with the idea that an eye, or a
This is something that I would really, really hope we can avoid. Yes, I understand. It really only arises if we have a class for tangible things. Making ‘tangible thing’ a key classifier is problematic for software as well. Perhaps we don’t need that if we focus on a more functional taxonomy. It is probably more about agency, or ‘implementation’, than tangibility. From: kjano [mailto:notifications@github.com] Hi Simon, I see your point. I am fine with changing Observer to Platform as long
This is something that I would really, really hope we can avoid. Most Best, On 07/27/2016 05:22 PM, Simon Cox wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edumailto:jano@geog.ucsb.edu — |
|
I always have the schema.org audience in mind and this is why I want to keep the Device (or SensingDevice), because in my opinion it is much more descriptive than Platform. Platform sounds vague and in SSN it really is used for a Sensor Network. I am currently working on my proposal, I can see the case for Observer and I am actually leaving it in there, but for me an Observer can never be a device, it is an Agent/Human. The Oxford dictionary (http://www.oxforddictionaries.com/definition/english/observer) agrees with me on that one. I would want to keep a Device and Observer class in the core, if people think that human sensor are important enough to keep in the core. From: kjano notifications@github.com Hi Simon, I see your point. I am fine with changing Observer to Platform as long
This is something that I would really, really hope we can avoid. Most Best, On 07/27/2016 05:22 PM, Simon Cox wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu — |
|
Apologies Jano, I just inadvertently overwrote your changes from yesterday on the main branch when I pushed my changes up. I wanted them to go to my branch, however, I forgot to change my branch locally (which was still set to the main branch, a leftover from earlier when I had to merge back the SSN document to the main branch). Maybe we both should push both our version to our own branches? It is pretty much the version from yesterday with the Activity and the Platform removed. I have kept the Device and I kept the Observer from your earlier change, but the Observer is not a device and in my opinion it should be disjoint from a Device in the vertical modules. I kept Observation as is. I don’t have a strong opinion on Observation. I think it would be better named Observing, but that’s up to you Simon. I kept the Procedure and its subclasses. If we don’t want sub-classing in the core we can remove the Procedure and just keep the more specific Procedures. From: kjano notifications@github.com Hi Armin,
Sure. I did this so we have a proposal on the table for the next round
I see your point but then Observation becomes an Activity too and as we
Yes, but the S really stands for Sensor. Maybe we should rename the
Yes, but this is not lost. It is called the Observer. The problem with
Great, thanks. Looking forward to seeing your changes and to pushing Jano On 07/27/2016 04:24 PM, Armin Haller wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu — |
|
Hi, No problem. I always have a version in my local branch but we should Cheers, On 07/27/2016 06:58 PM, Armin Haller wrote:
Krzysztof Janowicz Geography Department, University of California, Santa Barbara Email: jano@geog.ucsb.edu |
|
For some reason I am posting in Armin's name. See above, no idea why... |
|
Hi Armin, I think you also removed all other changes I made including fixing punctuation, correcting namespaces, and so forth? Jano |
|
Hi Jano, I used your version from yesterday, but did make changes to some comments and also fixed some typos (which looks like I reverted back in some cases, because some classes were gone). I did not understand your namespace change, it appeared to double the schema.org namespace, so I just kept yours from yesterday. I don’t really know how to push my changes to my branch now if the main branch is up to date. Cheers, From: kjano notifications@github.com Hi Armin, I think you also removed all other changes I made including fixing punctuation, correcting namespaces, and so forth? Jano — |
|
I will simply put the master back to what it was 5 hours ago. You should then be able to locally branch this and then make your changes in your local branch. My local changes are also in my local branch, so we are fine. Probably we should establish some procedure how to best do this, especially if multiple people start working on local branches. Cheers, |
|
Ø I kept Observation as is. I don’t have a strong opinion on Observation. I think it would be better named Observing, but that’s up to you Simon. I agree that it would be helpful to be consistent. I considered making that change already myself, particularly looking at the diagrams on the Wiki page https://www.w3.org/2015/spatial/wiki/File:Activity.png |
|
I would keep Observation and Actuation and remove Activity. As I said before, I would also propose to stay entirely away from the discussion whether this is an event and information object or something else for SOSA-core. IMHO, and I do realize that we all have our hobby horses and use cases, I would suggest to have Sensor, Observation, Actuation, Platform (which IMHO covers most of 'Device'), SamplingFeature,FeatureOfInterest, ObservedProperty, Result, Sensor, Procedure, and Actuator in SOSA-core -- nothing more. We should keep in mind that this is a OWA-based ontology, not a data model. The lack of a class does not imply that somebody cannot introduce it, subclass or superclass SOSA-core parts, and so forth. If you guys believe that we absolutely need Device, I will not object in the next telco as long as we finally get a chance to move this forward :-). |
|
I have added committed my changes again, this time to my own branch https://github.com/w3c/sdw/blob/armins-branch/ssn/rdf/sosa.ttl As mentioned, Activity is removed, but Observation and Actuating is kept. In the description, we can still call it an activity though, it is an activity in the real world after all. I am agnostic about the Procedures in the core. I thought you introduced that? I don’t feel strongly about it in the core. From: kjano notifications@github.com I would keep Observation and Actuation and remove Activity. As I said before, I would also propose to stay entirely away from the discussion whether this is an event and information object or something else for SOSA-core. IMHO, and I do realize that we all have our hobby horses and use cases, I would suggest to have Sensor, Observation, Actuation, Platform (which IMHO covers most of 'Device'), SamplingFeature,FeatureOfInterest, ObservedProperty, Result, Sensor, and Actuator in SOSA-core -- nothing more. We should keep in mind that this is a OWA-based ontology, not a data model. The lack of a class does not imply that somebody cannot introduce it, subclass or superclass SOSA-core parts, and so forth. If you guys believe that we absolutely need Device, I will not object in the next telco as long as we finally get a chance to move this forward :-). — |
|
Great. Thanks Armin.
Sorry for that. I simply forgot it. IMHO, Procedure it key. Please let us leave it in there.
I am fine with this. I would prefer to call it Actuation to keep the language clear and in line.
So basically the argument against Observer was that it does not include hosting actuators. This is a fair point. So we are still looking for that thing that hosts sensors and actuators. As I said before, I would be unhappy with Device but would be okay with the more abstract Platform. It looks like you feel exactly the other way around. Maybe we should introduce a new and neutral term such as a Carrier or Host. Would that work for you (and @dr-shorthair (and everybody else))? IMHO, a new term is often a good choice as it is not so loaded with years of previous interpretations.
Can you explain why we would need Sensing? I think I am really missing something here. When exactly would you create a Sensing instance and what would you use it for? I would just have Observation and nothing more but I understand that this excludes the Actuators and thus I am fine with having Actuation in there as well. |
|
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 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? |
Removed Activity and changed descriptions that made use of it. Renamed Observer to Host and adjusted description. Changed SamplingFeature to Sample and changed description. Added Actuation. Reworked the relations to fit the new/changed classes (e.g., they were all restricted to observations only). If you would like to make changes, please start from this version (it is based on discussions around #309 and #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).