Re: Link between FeatureOfInterest and xxxProperty from Maxime Lefrançois on 2017-02-26 (public-sdw-wg@w3.org from February 2017)

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Sun, 26 Feb 2017 13:45:13 +0000
To: Simon.Cox@csiro.au, rgarcia@fi.upm.es, rob@metalinkage.com.au
Cc: public-sdw-wg@w3.org
Message-ID: <CALsPASXmmN9UojUaEVNe1fAcdraw=BjAbzSkUoO_3sfRWYd0BA@mail.gmail.com>
Dear Rob, Raúl, Simon,

Please find below some reactions to your mails.
(in this mail, sosa:hasProperty and ssn:hasProperty are used
interchangeably)


to Rob;

Someone that defines a sub-class of FeatureOfInterest should also define
the properties applicable to that class as sub-properties of
sosa:hasProperty. This would make explicit the "substitution" you are
refering to.

SEAS encourages this, plus we encourage to model sub-properties of
sosa:hasProperty as functional.

As an example:

  seas:ElectricPowerSystem a owl:Class ;
    rdfs:subClassOf ssn:FeatureOfInterest ...

  seas:consumedElectricPower a owl:ObjectProperty , owl:FunctionalProperty ;
    rdfs:subPropertyOf ssn:hasProperty ;
    rdfs:domain seas:ElectricPowerSystem ...

  <fridge/1> a seas:ElectricPowerSystem ;
    seas:consumedElectricPower <fridge/1/consumption> .



to Raúl,

I added a section "What is an instances of ssn:Property ?" to the wiki page
[1].  The intent is to compare the different ways that oldssn:Property is
defined versus how it's used.

I am surprised to see that some datasets define instances of ssn:Property
that are not strongly bound to some feature of interest. Do you think this
still conforms with the definition of ssn:Property ?



to Rob again,

you mention sosa:featureOfInterestType, what is this link ?

I don't remember precisely of all my modeling attempts to associate
multiple values to different properties, but I remember that I tried hard
with RDF QB.
 1. First proposal was similar to the one you suggest, i.e., have some
generic measure component seas:consumptionMeasure, and a dimension
component seas:featureOfInterest. If I remember well, some problem arise if
you want to describe the consumption of both foi A and foi B in the same
dataset.
 2. second attempt was to bind the feature of interest directly to the
component specification. I think this one worked better, but some of the
partners refused to use RDF Data Cube and wanted some simpler vocabulary to
associate different values to different properties, at once.

In the end, our seas:hasOutput property (which will shortly be renamed
seas:hasResult to be aligned to the outcome of this group), is loosely
defined and can link to:
 - a RDF qb:DataSet,
 - one or more instances of seas:Evaluation [2] at once,
 - one or more URIs that act as names of RDF graphs,
 - ...

This has proven to be very flexible and account for several use cases.




to Simon,

I'm not very familiar to UML with metaclasses etc. Is it correct to say
that in the ISO 19109,
 - ElectricPowerSystem would be modeled as a class, and an instance of the
metaclass FeatureType,
 - ConsumedElectricPower would be modeled as a class, and an instance of
the metaclass PropertyType,
 - ElectricPowerSystem would have carrierOfCharacteristics
ConsumedElectricPower, but potentially not only
 - ConsumedElectricPower would have theFeatureType ElectricPowerSystem, but
potentially not only
 - fridge1 would be an instance of ElectricPowerSystem,
 - frige1consumption would be an instance of ConsumedElectricPower

then what would be the property of fridge1 that points to frige1consumption
?


If I attempt to align this model with SSN, then I would say that ISO 19109
properties is better aligned to the ssn:hasProperty property than to the
ssn:Property class:

"sub-properties of ssn:hasProperty are strongly bound with the sub-class of
ssn:FeatureOfInterest that they apply to  (strongly bound here = their
domain is the sub-class of ssn:FeatureOfInterest). "


The changes that you pushed into ISO 19109:2015 are very interesting,

(i) following this change, we should discourage SSN users to define the
domain of a ssh:hasProperty, but instead rely on local restrictions at the
level of the sub-class of ssn:FeatureOfInterest.

i.e., if some FeatureType ElectricPowerSystem is the carrier of some
characteristics ConsumedElectricPower, then we could map this to SSN as
follows:

  seas:ElectricPowerSystem a owl:Class ;
    rdfs:subClassOf ssn:FeatureOfInterest ;
    rdfs:subClassOf [
      owl:onProperty seas:consumedElectricPower
      owl:someValuesFrom owl:Thing ] .

  seas:consumedElectricPower a owl:ObjectProperty , owl:FunctionalProperty ;
    rdfs:subPropertyOf ssn:hasProperty ;


(ii) this is where the SEAS model diverges from ISO 19109: Properties are
assigned some value using class seas:Evaluation [2], which is not a
super-class of ssn:Observation. One or more evaluations may be used as some
command for an Actuation. One or more evaluation may be the result of a
seas:Observation, a seas:OptimizationExecution, or a seas:Forecast [3]. I
like the name "ValueAssignment" though and would have been tempted to use
it in place of "Evaluation". Unfortunately, this could bring some confusion
to the people that are familiar to ISO 19109.


Kind regards,
Maxime

[1] -
https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty
[2] - https://w3id.org/seas/Evaluation
[3] - https://w3id.org/seas/OptimizationExecution
[4] - https://w3id.org/seas/Forecast

Le sam. 25 févr. 2017 à 05:27, <Simon.Cox@csiro.au> a écrit :

Whoops - attached the wrong part of Figure 5 - here's the bit that matters.

-----Original Message-----
From: Cox, Simon (L&W, Clayton)
Sent: Saturday, 25 February, 2017 15:01
To: 'Raúl García Castro' <rgarcia@fi.upm.es>; Rob Atkinson <
rob@metalinkage.com.au>
Cc: Maxime Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List <
public-sdw-wg@w3.org>
Subject: RE: Link between FeatureOfInterest and xxxProperty

The relevant standard from the OGC/ISO TC 211 world is ISO 19109 "Rules for
Application Schema" which describes the 'General Feature Model' in which
feature-types are defined in terms of their properties - i.e. properties
are strongly bound with the feature-types that they apply to. Its really
just standard object modelling, but dressed up to use terminology from the
geospatial domain (i.e. "Features" instead of real-world-objects).

I was the editor for the most recent edition of ISO 19109:2015, and managed
to get a couple of significant changes relevant to our work here
incorporated
(i) a strong recommendation that properties should be defined and names
carefully to allow them to be re-used on different feature types
(ii) a meta-class for "ValueAssignment" with "Observation" as one of the
concrete instantiations.

Unfortunately the document is behind ISO's paywall, but I've attached the
three key figures here.

Also see Figure 2 in the OGC/ISO standard for O&M, available from
http://www.opengeospatial.org/standards/om (get Topic 20, not the XML
implementation).

Simon

-----Original Message-----
From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
Sent: Friday, 24 February, 2017 22:43
To: Rob Atkinson <rob@metalinkage.com.au>
Cc: Maxime Lefrançois <maxime.lefrancois@emse.fr>; SDW WG Public List <
public-sdw-wg@w3.org>
Subject: Re: Link between FeatureOfInterest and xxxProperty

Dear all,

I think that being able to represent which properties relate to a certain
feature is a requirement needed both in SOSA and in SSN.

For example, in the SSN usage analysis
(http://w3c.github.io/sdw/ssn-usage/), even if it is not exhaustive, 3
ontologies and 2 datasets use the SSN properties to do so.

So I propose to open an issue to study this in deeper detail.

Kind regards,

El 24/2/17 a las 12:18, Rob Atkinson escribió:
>
> the FeatureOfInterest is an abstract class that a domain Class will be
> mapped to in an implementation - so the properties being measured are
> references to the properties defined in that class - i.e. I dont think
> we need to define the link that direction other than somehow stating
> this substitution
>
> i.e. perhaps  its defined in the implementation by making a statement
> that domain:Class rdfs:subClassOf sosa:FeatureOfInterest or even that
> there is a restriction on the range on sosa:featureOfInterest to be
> domain:Class
>
> I think its worth an OWL expert to lay out the exact options here in
> examples.
>
> Rob
>
>
>
>
> On Fri, 24 Feb 2017 at 02:24 Maxime Lefrançois
> <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>> wrote:
>
>     Dear all,
>
>     Implementing ACTION-268, I stumbled again on the fact that there is
>     currently no link between FeatureOfInterest and xxxProperty defined
>     in SOSA.
>     See also the figure attached
>     to
> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0090.html
>     .
>
>     I would like us to discuss this shortly during the next call, there
>     are two simple options that I listed in the following wiki page:
>
>
> https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_an
> d_xxxProperty
>
>     For your interest, in one of the core SEAS ontologies we promote the
>     definition of  "functional sub-properties of ssn:hasProperty". See
> [1].
>
>     For example, some domain ontology would define:
>
>     ex:consumption a owl:ObjectProperty , owl:FunctionalProperty ;
>       rdfs:subPropertyOf seas:hasProperty ;
>
>     Then in static instance data:
>
>     <fridge/1> a seas:FeatureOfInterest ;
>       ex:consumption <fridge/1/consumption> .
>
>     Core ontology seas:EvaluationOntology defines various ways to give
>     such Property a value.
>
>     [1] - https://w3id.org/seas/FeatureOfInterestOntology
>
>     Kind regards,
>     Maxime
>



--

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> - Fax: +34 91 352 48 19
<+34%20913%2052%2048%2019>
Received on Sunday, 26 February 2017 13:46:05 UTC