Re: Link between FeatureOfInterest and xxxProperty

It seems to me we have a few possible ways to manage links - all with pros
and cons.

i would like to consider the Use Case where the digital representation of a
feature is in existence, and for simplicity let us assume its already
modelled (there is an OWL model) and its instances are dereferenceable
(Linked Data) and hence we only have to worry about referencing these, not
building the referencing mechanism.

Such an instance may be generated through some official channel - such as
designation of a road as a public highway, registration of a land parcel,
official naming of a hydrologic unit for management purposes.

in this case neither the instances nor the models are mutable - we can make
statements about them but we cant make those statements discoverable by
resolving the URIs - the classic Open World, AAA and non-unique naming
situations.

In general - the ObservedProperty may not be referenced in the original
model or instance data  - AAA - so maybe its always necessary to use SSN to
declare such properties - and the pattern proposed is necessary and
sufficient.

AFAICT the main options before we get to the detailed options in [1] are:
1) extend the model of the FoI - define our own graph and add statements
about the foi class that make it substitutable for sosa:FeatureOfInterest,
as per [1]
2) leave the range of sosa:featureOfInterest open, and declare the type of
the foi in implementations (soft-typing) - requiring a new property foiType
3) Always reference the FoI via an intermediate samplingFeature, which must
be defined using SSN semantics, and may reference the original immutable FOI
4) ?

If we take this AAA case further, imagine a virtual observatory with data
from a million different citizen science projects, each having modelled its
FOI using project specific SSN as per the suggested pattern, and the data
all being available in the same graph (i.e. we could slice a repository by
FOI and get a massively varied number of observations about that feature).
We may have many different observation activities about the same property,
but done at different times, or using different methods to compare,
validate etc.

The questions I have are:

 - how safe are we to have many SSN models of FOI, some referencing the
same property, others declaring the same sampling method/sensor etc on a
different property using the Option1 pattern?
- is it worth focusing on the sampling pattern, with the SSN description of
the samplingFeature as basic practice, and have guidance for how this
collapses to simply describing properties of an externally defined
Feature?

Maybe all is good, but I for one would like to see evidence of safety of
more than one SSN description within a graph.

Rob

[1] -
https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty


On Mon, 27 Feb 2017 at 00:45 Maxime Lefrançois <maxime.lefrancois@emse.fr>
wrote:

> 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>
>
>