- 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