Re: Linking Systems and Features of Interest

Hi,

In a matter of completeness, let me first paste the most important part of
https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty#What_is_an_instances_of_ssn:Property_.3F

with some additional formatting.

*In oldSSN:* An observable Quality of an Event or Object. That is, not a
quality of an abstract entity as is also allowed by DUL's Quality, but
rather **an aspect of an entity that is intrinsic to and cannot exist
without the entity** and is observable by a sensor.

*In sections in https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628
<https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628>:*

*5.3.1.2.4 Observed Properties:* Properties are qualities that can be
observed via stimuli by a certain type of sensors. They inhere in features
of interest and **do not exist independently**. While this does not imply
that they do not exist without observations, our domain is restricted to
those observations for which sensors can be implemented based on certain
procedures and stimuli. To minimise the amount of ontological commitments
related to the existence of entities in the physical world, observed
properties are the only connection between stimuli, sensors, and
observations on the one hand, and features of interests on the other hand.

*5.3.1.3.4 Observed Properties:* ObservedProperty is defined as a subclass
of DUL:Quality. **Types of properties, such as temperature or pressure
should be added as subclasses of ObservedProperty instead of individuals**.
A new relation called SSO:isPropertyOf is defined as a subrelation of
DUL:isQualityOf to relate a property to a feature of interest.
*5.4.3.6 Wind Feature and properties:* This example also includes a
definition for Wind as a Feature of Interest with two properties: wind
direction and wind speed.


My conclusions, as Raul acknowledges, is that:
 1. type of property :Occupancy should be a class instead of an individual
 (probably also a sub-class of sosa:ObservableProperty)
 2. :roomXOccupancy and :buildingXOccupancy should be instances of
:Occupancy (and :sosa:ObsevableProperty), that do not exist independently
of :roomX and :buildingX, respectively
 3.  in OWL, an occupancy sensor could be defined as a sensor that observes
occupancy as follows:

:OccupancySensor owl:equivalentClass [ a owl:Restriction ; owl:onProperty
sosa:observes ; owl:allValuesFrom :Occupancy ] .

 4. to retrieve all the occupancy observations, one may just execute the
following SPARQL query:

SELECT ?observation WHERE {
  ?observation sosa:observedProperty ?property .
  ?property a :Occupancy .
}

or only those of :buildingX

SELECT ?observation WHERE {
  ?observation sosa:observedProperty ?property .
  ?property a :Occupancy .
  ?property ssn:isPropertyOf :buildingX .
}

or only those of :buildingX or its samples

SELECT ?observation WHERE {
  ?observation sosa:observedProperty ?property .
  ?property a :Occupancy .

{ ?property ssn:isPropertyOf :buildingX . }
 UNION  { ?property ssn:isPropertyOf ?sample . ?sample sosa:isSampleOf
:buildingX . }

}

This is no game changer because it was there since the beginning, but it
may help us consider moving ssn:hasProperty and ssn:isPropertyOf into SSN ?

Best,
Maxime


Le mar. 2 mai 2017 à 17:46, Krzysztof Janowicz <janowicz@ucsb.edu> a écrit :

> Hi,
>
> I may be overlooking the point here but occupancy should be the
> ObservedProperty, not RoomXOccupancy and BuildingXOccupancy. Otherwise
> you could not ask for the occupancy of multiple buildings. This is also
> how others do it, often calling it measurement type. There is a 1:n
> relation between the observed property and the features of interest (and
> observations).
>
> Best,
> Jano
>
>
> On 05/02/2017 04:56 AM, Raúl García Castro wrote:
> > 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 <+34%20913%2036%2065%2096>
> <tel:+34%20913%2036%2065%2096> - Fax: +34 91
> >>     352 48 19 <tel:+34%20913%2052%2048%2019>
> >>
> >
> >
>
>
> --
> 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
>
>