W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: Link between FeatureOfInterest and xxxProperty

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Tue, 28 Feb 2017 11:23:15 -0800
To: Rob Atkinson <rob@metalinkage.com.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>, Simon.Cox@csiro.au, rgarcia@fi.upm.es
Cc: public-sdw-wg@w3.org
Message-ID: <fdfe1bb5-6ed8-fae5-5cbe-563194d49235@ucsb.edu>
Hi,

So, I thought about this for a while and I see 3 major problems (and a 
few smaller issues).

First, we would need to agree what exactly we want to model. Is this 
going to be a relation between types or between types and individuals or 
between individuals?

Second, while I like the idea in general, do we want to introduce such 
substantial changes to SSN (and potentially SOSA) so late in the 
process? I am not sure what the answer to this should be, but I remember 
Kerry being very concerned about even the smallest changes made to SSN. 
We would certainly need to come up with implementation evidence.

Third, I think the idea of using functional properties may lead to 
issues for some features and the idea of samples, e.g., for the depth of 
waterbodies, but I have to think about this a bit more.

Cheers,
Jano



On 02/26/2017 02:05 PM, Rob Atkinson wrote:
>
> 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 <mailto: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
>         <mailto:rgarcia@fi.upm.es>>; Rob Atkinson
>         <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>
>         Cc: Maxime Lefrançois <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>; SDW WG Public List
>         <public-sdw-wg@w3.org <mailto: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
>         <mailto:rgarcia@fi.upm.es>]
>         Sent: Friday, 24 February, 2017 22:43
>         To: Rob Atkinson <rob@metalinkage.com.au
>         <mailto:rob@metalinkage.com.au>>
>         Cc: Maxime Lefrançois <maxime.lefrancois@emse.fr
>         <mailto:maxime.lefrancois@emse.fr>>; SDW WG Public List
>         <public-sdw-wg@w3.org <mailto: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>
>         <mailto: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 <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
Received on Tuesday, 28 February 2017 19:54:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 February 2017 19:54:05 UTC