Re: What is a property?

Thanks Maxime, your first model below is my understanding of our modelling. However, I don’t think Occupancy is the best example to use here and for our examples in the document. Since the room is a (stationary) Spatial Object you could relate it to its Feature of Interest with some other (spatial) property rather than ssn:hasProperty. If we use the example of measuring the temperature of a human being that Krzysztof proposed, the example becomes probably easier to understand.

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Monday, 8 May 2017 at 10:03 pm
To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "rgarcia@fi.upm.es" <rgarcia@fi.upm.es>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, Armin Haller <armin.haller@anu.edu.au>
Subject: Re: What is a property?

Hi Simon, all,


Let me propose a translation of the ISO 19109 model to RDF:

(1) there are Feature-types (classes), and Features of interest (instances of those classes)
--> Feature-types are RDFS/OWL Classes, they are sub-classes of sosa:FeatureOfInterest, and their instances are Features of Interest

ex1: ex:Room is a RDFS/OWL class that represents a Feature-type, and <roomX> is an instance of that class that represents a Feature (of Interest)
ex2: ex:Building is a RDFS/OWL class that represents a Feature-type, and <buildingX> is an instance of that class that represents a Feature (of Interest)

(2) there are properties, and these properties may have instances.
--> properties are RDFS/OWL Classes, sub-classes of sosa:ObservableProperty (and by transitivity, also of ssn:Property), and their instances are named "property instances".

ex: ex:Occupancy is a RDFS/OWL class that represents a Property. <buildingXoccupancy> and <roomXoccupancy> are instances of that class and represent "property instances".


Then:

(a) a property instance cannot exist in the absence of a feature (of interest)

ex1:  <buildingXoccupancy> cannot exist in the absence of <buildingX>
ex2: <roomXoccupancy> cannot exist in the absence of <roomX>

(b) Feature-types (classes) are characterized by a set of properties

ex1:  ex:Building is characterized by a set of properties, and this set contains property ex:Occupancy

ex:Building rdfs:subClassOf [
  owl:onProperty ssn:hasProperty ;
  owl:someValuesFrom ex:Occupancy ] .

<buildingX> rdf:type ex:Building   ;
  ssn:hasProperty <buildingXoccupancy> .

<buildingXoccupancy> rdf:type ex:Occupancy .


(c) But each (well most, anyway) property may relate to more than one feature-type (and implicitly to many more than one individual feature)
--> ex:Occupancy can relate to more than ex:Building, it can also relate to ex:Room.

ex:Room rdfs:subClassOf [
  owl:onProperty ssn:hasProperty ;
  owl:someValuesFrom ex:Occupancy ] .

<roomX> rdf:type ex:Room ;
  ssn:hasProperty <roomXoccupancy> .

<roomXoccupancy>  rdf:type ex:Occupancy .



To me, everything is fine there:
 - what is named "xxx-type" is translated in RDFS/OWL as a class
 - what is named "xxx instance" is translated in RDFS/OWL as an instance

ex1: for Feature-type and feature (of interest)
- Feature-types are translated in RDFS/OWL as classes
- Features (of interest) are translated in RDFS/OWL as instances.

ex1: for properties and their instances:
- observable (and actuatable) properties are made classes
- instances of theses properties are instances.



If instead we want to translate ISO 19101 properties into rdf:Properties (or owl:ObjectProperties), then [1] and [2] propose some way to do it, that is totally compatible with the above description. The suggestion would be to translate ISO 19101 properties into both:
  1. a sub-class of sosa:ObservableProperty, and
  2. a (functional) sub-property of ssn:hasProperty


ex:occupancy a owl:ObjectProperty , owl:FunctionalProperty ;
  rdfs:subPropertyOf ssn:hasProperty ;
  rdfs:range ex:OccupancyProperty .

ex:OccupancyProperty a rdfs:Class ;
  rdfs:subClassOf sosa:ObservableProperty .

 ex:Building rdfs:subClassOf [
  owl:onProperty ex:occupancy   ;
  owl:someValuesFrom ex:OccupancyProperty ] .

ex:Room rdfs:subClassOf [
  owl:onProperty ex:occupancy ;
  owl:someValuesFrom ex:OccupancyProperty ] .


<buildingX> rdf:type ex:Building   ;
  ex:occupancy <buildingXoccupancy> .

<buildingXoccupancy> rdf:type ex:Occupancy .

<roomX> rdf:type ex:Room ;
  ex:occupancy <roomXoccupancy> .

<roomXoccupancy>  rdf:type ex:Occupancy .


Any comments?

Best,
Maxime

[1] - https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0478.html

[2] - https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0515.html


Le lun. 8 mai 2017 à 02:49, <Simon.Cox@csiro.au> a écrit :
ISO 19109 model in its revised form says

(a)   A property instance cannot exist in the absence of a feature (of interest)

(b)   Feature-types (classes) are characterized by a set of properties

(c)    But each (well most, anyway) property may relate to more than one feature-type (and implicitly to many more than one individual feature)
This was intended to respect both the ISO 19101 reference model, and the semantic web toolkit.

When working in the RDFS/OWL world we could just make these observable (and actuatable) properties RDF properties. i.e.

ssn:Property owl:equivalentProperty rdf:Property .

is OK to me, but because of the way that rdf:Property is built-in to RDF itself, I’m not sure if the meta-model allows us to go on to say

sosa:ObservableProperty rdfs:subClassOf ssn:Property .

and then

sosa:Observation
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:allValuesFrom sosa:ObservableProperty ;
      owl:onProperty sosa:observedProperty ;
    ] .

(or sosa:observedProperty rdfs:range sosa:ObservableProperty . )

Simon

From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>]
Sent: Saturday, 6 May, 2017 03:26
To: Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>; Raúl García Castro <rgarcia@fi.upm.es<mailto:rgarcia@fi.upm.es>>; SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>
Subject: Re: What is a property?

Hi,

See also Simon's message "In fact in ISO 19109 revision I made sure that we left the door open for properties to not be even tied to just one feature-type, so that the notion of 'colour' or 'mass' could be denoted with the same token regardless of which feature-type it is associated with. i.e. no global domain contraints ..."

@Krzysztof, what do you mean by axiomatic perspective ?

That from the point of view of the axioms both ways would be acceptable.

Are you sure the intended one is really the second example ? Intended by who ?


I mean the example where there is one such thing as 'temperature' (which is an ObservableProperty). Whenever you observe, you may involve different sensors and carry out your observation on different features. While this will create a 'new' observation every time, the ObservableProperty will always stay the same. This is also comparable to the notion of a procedure. To the very best of my knowledge, this is how all the measurement type code lists that I am aware of work, e.g., http://vocab.nerc.ac.uk/collection/A04/current/AverageWindSpeed/.


Best,
Krzysztof

On 05/05/2017 09:21 AM, Maxime Lefrançois wrote:
Hi Krzysztof, Raúl, all,

I will also point to the resources:
- https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty#What_is_an_instances_of_ssn:Property_.3F

- https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0336.html


@Krzysztof, what do you mean by axiomatic perspective ? Are you sure the intended one is really the second example ? Intended by who ?

It really looks to me like only (1) conforms to the original SSN spec.

What I love from (1) is that we can indeed, as Krzysztof mentions, express *both* the Property <OccupancyBuildingX>, and the Property *Type* ex:Occupancy:

ex:Occupancy rdfs:subClassOf sosa:ObservableProperty.
<OccupancyBuildingX> a ex:Occupancy   ;
     ssn:isPropertyOf ns:BuildingX .
<OccupancyBuildingY> a ex:Occupancy   ;
     ssn:isPropertyOf ns:BuildingY .

This solution has all the advantages of solutions (1) and (2), while being perfectly aligned with the original SSN spec, and cover the competency questions that Raúl and Armin were mentioning.

In addition, Krzysztof brings up one more competency question that (1) covers, while (2) does not:
- It is possible to extend SOSA/SSN with some vocabulary to describe for instance that: "temperature of body1 is less than of body2". With (2), there is no such concept as "temperature of body 1".


So my final suggestion would be to make it clear in the spec and the examples that we adopt (1). I believe it's little effort to adapt existing datasets that were using (2) to the (better/original/new) approach (1)


Examples will be highly impacted by the final decision to this question, I will hence delay ACTION-350 until then.

Best,
Maxime Lefrançois

Le ven. 5 mai 2017 à 17:20, Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> a écrit :
Hi,

Both uses are okay from an axiomatic perspective, but the indented one
is the second example. It is worth noting that they are not as different
as they may seem because (1) can be made very similar to (2) by adding a
subclassing axiom that states

Occupancy rdfs:subClassOf ObservableProperty.

and then change

ns:OccupancyBuildingX a ssn:Property ; [KJ: should be ObservableProperty]
...

to

ns:OccupancyBuildingX a Occupancy.

The question is rather how specific we should be to foster
interoperability between different datasets, and, IMHO, we should
clearly state what we mean. There is a 1:2 relation between observable
properties and features  (and observations). Science works because no
matter how often we measure the temperature of a body and how many
different sensors and bodies we use, the measured property is of the
same kind, namely temperature. This, for instance, makes sure that we
can state that the temperature of body1 is less than of body2 and so on.

Best,
Jano


On 05/05/2017 07:50 AM, Raúl García Castro wrote:
> Dear all,
>
> Taking a look to a previous thread
> (https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0335.html)
> and to a recent pull request conversation
> (https://github.com/w3c/sdw/pull/792) it seems that there are two
> views on what a property is.
(1)
> Is it something intrinsic to a feature?
>   ns:OccupancyBuildingX a ssn:Property ; [KJ: should be
> ObservableProperty]
>     ssn:isPropertyOf ns:BuildingX .
>   ns:OccupancyBuildingY a ssn:Property ; [KJ: should be
> ObservableProperty]
>     ssn:isPropertyOf ns:BuildingY .

(2)
>  Or is it something independent of a concrete feature?
>   ns:Occupancy a ssn:Property ; [KJ: should be ObservableProperty]
>     ssn:isPropertyOf ns:BuildingX .
>     ssn:isPropertyOf ns:BuildingY .
>
> For those familiar with QUDT, is a Property related to a qudt:Quantity
> (first option above) or to a qudt:QuantityKind (second option)?
>
> Note that both options are supported by current definitions and usage
> information, so we need to define clearly what we understand as a
> Property and update the definitions and examples to leave it clear.
>
> Kind regards,
>


--
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>
Webpage: http://geog.ucsb.edu/~jano/<http://geog.ucsb.edu/%7Ejano/>
Semantic Web Journal: http://www.semantic-web-journal.net





--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net