Re: Linking Systems and Features of Interest

Hi Maxime,

Thanks for enlightening me!

I don't know why suddenly I overlooked that thread (even if I should not 
have done it).

I answer below your comments.

El 28/4/17 a las 19:58, Maxime Lefrançois escribió:
> Hi Raul,
>
> I agree that being able to answer:
>
> "what are the sensors that observe that specific feature of interest?"
>
> seems quite important. Before argumenting further,  I'd like to share my
> concerns about way you use class ObservableProperty in your examples:
>
> You use instance ns:Occupancy as the observable property of two
> different features of interest, yet this is not correct with respect to
> the definition of ObservableProperty: "An observable quality (property,
> characteristic) of a FeatureOfInterest.".
> ssn:Property further adds: "A quality of an entity. An aspect of an
> entity that is intrinsic to and cannot exist without the entity."
>
> So ns:Occupancy should either be the quality of ns:RoomX, or
> ns:BuildingX. But not both.
>
> We already discussed about "what is an instance of ssn:Property" in March:
> - see wiki page
> section https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty#What_is_an_instances_of_ssn:Property_.3F
> - and thread starting with this
> mail: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0478.html

In my mind a Property has always been something generic (a quality of an 
abstract entity) and not something related to a concrete feature of 
interest.

My wrong, since your comment is absolutely right. It has been like that 
since the beginning.

Going back to the wiki page and to how ssn:Property has been used 
(https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty#Usage_in_referenced_Datasets), 
I think that all the datasets (including D3 and D10) also have that in mind.

For example, in D3, 
http://vocab.linkeddata.es/datosabiertos/def/transporte/tarjetaTransportePublico#entradaUsuario 
is a generic property that applies to every public transport card. If 
you DESCRIBE a couple of observations about entradaUsuario you can see 
that they refer to different features of interest.

In D10, the defined properties (air_temperature, wind_speed) can also be 
understood as generic since their features of interest are also generic 
(air and wind, respectively).

For me, it is straightforward to represent properties as generic ones, 
so anyone can ask: "give me temperature observations" or define: "a 
temperature sensor is a sensor that observes temperature".

If "temperature" is a class, doing those things is not so straightforward.

For example, going back to the examples in the wiki page, how would you 
define in OWL an occupancy sensor as a sensor that observes occupancy?

In any case, here we have another example in which providing usage 
examples is needed to avoid mistakes.

> So if we accept to conform to the old (and the new) definition, your
> examples could be rewritten as follows:
>
> ns:mySensor a sosa:Sensor ;
>    sosa:observes ns:RoomXOccupancy .
>  ns:RoomXOccupancy a sosa:ObservableProperty ;
>    ssn:isPropertyOf ns:RoomX .
>  ns:RoomX a sosa:FeatureOfInterest .
>
> ns:anotherSensor a sosa:Sensor ;
>    sosa:observes ns:BuildingXOccupancy .
>  ns:BuildingXOccupancy a sosa:ObservableProperty ;
>    ssn:isPropertyOf ns:BuildingX .
>  ns:BuildingX a sosa:FeatureOfInterest .
>
> and it is actually easy to ask: "what are the sensors that observe
> feature of interest ns:RoomX ?" as follows:
>
> SELECT ?sensor WHERE {
>   ?sensor sosa:observes ?property .
>   ?property sosa/ssn:isPropertyOf ns:RoomX .
> }

Yes, now it is straightforward because, in fact, there is a 1-1 
relationship among a property and the feature it belongs to.

> On the other hand:
>
> 1. This is true in SSN, but hasProperty/isPropertyOf must be moved to
> sosa so that it becomes true in SOSA.
> 2. Even then, this would only be true for sensors, (because there is no
> property parallel to sosa:observes for actuators)
 >
> Last point I would like to make is:
> During last call, some of the group members were afraid that moving
> hasProperty/isPropertyOf to SOSA would require that we also move
> Property to SOSA, which would in turn require to use the rdfs:subClassOf
> axiom.
>
> I think I managed to explain why I think this is not true during the call:
>
> we just move hasProperty/isProperty as follows:
>
>   ssn:hasProperty a owl:ObjectProperty ;
>     rdfs:label "has property"@en ;
>     skos:definition "Relation between an entity and a Property of that
> entity."@en ;
>     rdfs:comment "Relation between an entity and a Property of that
> entity."@en ;
>     owl:inverseOf ssn:isPropertyOf ;
>     rdfs:domainIncludes sosa:FeatureOfInterest ;
>     rdfs:rangeIncludes sosa:ObservableProperty ;
>     rdfs:rangeIncludes sosa:ActuatableProperty ;
>     rdfs:isDefinedBy sosa: .
>
>   ssn:isPropertyOf a owl:ObjectProperty ;
>     rdfs:label "is property of"@en ;
>     skos:definition "Relation between a Property and the entity it
> belongs to."@en ;
>     rdfs:comment "Relation between a Property and the entity it belongs
> to."@en ;
>     rdfs:domainIncludes sosa:ObservableProperty ;
>     rdfs:domainIncludes sosa:ActuatableProperty ;
>     rdfs:rangeIncludes sosa:FeatureOfInterest ;
>     owl:inverseOf ssn:hasProperty ;
>     rdfs:isDefinedBy ssn: .
>
>
> and the SSN only contains:
>
> ssn:hasProperty  a owl:InverseFunctionalProperty  ;
>     rdfs:isDefinedBy sosa: .
>
> ssn:isPropertyOf  a owl:FunctionalProperty  ;
>     rdfs:isDefinedBy sosa: .
>
>
> Do you believe that could be a sufficiently good proposal ?

I also agree that it can be made without moving ssn:Property to SOSA.

Taking into account the 1-1 relationship among a property and the 
feature it belongs to, if we move the properties to SOSA, it would 
support the discovery use case defined.

Kind regards,

> Le ven. 28 avr. 2017 à 19:03, Raúl García Castro <rgarcia@fi.upm.es
> <mailto:rgarcia@fi.upm.es>> a écrit :
>
>     Dear all,
>
>     I've been thinking on the issue of moving the ssn:isPropertyOf and
>     ssn:hasProperty properties to sosa. I still think that we need something
>     more in sosa, but I have realised that those properties are not the
>     solution.
>
>     The short summary is that I see the need for having in sosa a new
>     property that links systems to features.
>
>     The long discussion and proposal (with figures) is documented in the
>     wiki:
>     https://www.w3.org/2015/spatial/wiki/Linking_Systems_and_Features_of_Interest
>
>     Kind regards,
>
>     --
>
>     Dr. Raúl García Castro
>     http://www.garcia-castro.com/
>
>     Ontology Engineering Group
>     Departamento de Inteligencia Artificial
>     Escuela Técnica Superior de Ingenieros Informáticos
>     Universidad Politécnica de Madrid
>     Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
>     Phone: +34 91 336 65 96 <tel:+34%20913%2036%2065%2096> - Fax: +34 91
>     352 48 19 <tel:+34%20913%2052%2048%2019>
>


-- 

Dr. Raúl García Castro
http://www.garcia-castro.com/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19

Received on Tuesday, 2 May 2017 11:57:30 UTC