Re: Link between FeatureOfInterest and xxxProperty

Yeah its complicated... like healthcare apparently :-)

This is why I wonder if its not best to work on the samplingFeaturePattern
then provide a simple form where the FoI and the samplingFeature are the
same.

Soft-typing, where a property explicitly defines the type of the instance,
is at least explicit about the types/instances issue. Hopefully it wont
break existing SSN as its an optional method to add more information.



On Wed, 1 Mar 2017 at 06:23 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

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