- From: <Simon.Cox@csiro.au>
- Date: Thu, 9 Feb 2017 05:28:35 +0000
- To: <janowicz@ucsb.edu>, <rob@metalinkage.com.au>, <phila@w3.org>, <public-sdw-wg@w3.org>
- Message-ID: <df8acb1123614820a539f8436ed1c929@exch1-mel.nexus.csiro.au>
Yeah – I saw that, and commented on it indirectly with this: Ø > I doubt this would be helpful but we could perhaps mint new ones that did dereference and assert equivalence but that's only worth doing if it provides some functionality that's actually useful. Ø I'd be reluctant to head that direction. As I mentioned on the call and in my documentation, URIs in the def.isotc211.org<http://def.isotc211.org> domain are specified in ISO 19150-2, so putting another façade in front is really just obfuscation. From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu] Sent: Thursday, 9 February, 2017 15:32 To: Rob Atkinson <rob@metalinkage.com.au>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; phila@w3.org; public-sdw-wg@w3.org Subject: Re: Non-dereferencable URIs (was Re: ACTION-255 - o&m alignment) Simon, have you seen the suggestion below to mint local class and property URLs and align them (and use rdfs:isDefinedBy)? >I doubt this would be helpful but we could perhaps mint new ones that did dereference and assert >equivalence but that's only worth doing if it provides some functionality that's actually useful. I had the same (or similar) idea but it was already past 2 pm and we closed the meeting. What we could do is to have an ontology that has dereferencable URIs for all the classes and properties and for each of them would also contain rdfs:isDefinedBy statements that point to the O&M/ISO URIs. rdfs:isDefinedBy explicitly does not put any constraints on such resources, they do not even have to be Web-available (https://www.w3.org/TR/rdf-schema/#ch_isdefinedby). As a final step, we would establish our mapping axioms in the form of subclass and equivalence class relations from SOSA/SSN to these dereferenceable class and property URLs. On 02/08/2017 05:05 PM, Rob Atkinson wrote: +1 On Thu, 9 Feb 2017 at 11:25 <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au> wrote: > The question is, of course, can TC211 be encouraged to make things like http://def.isotc211.org/iso19156/2011/ dereferencable? If it helps, we'd happily host the relevant data to which those URIs could redirect (I'm sure OGC and others would too of course). I raised this with Jean Brodeur, who is the primary custodian of the GitHub repository. There is certainly an interest in making these things dereferencable. The blockers are - resourcing - limited DNS/HTTP knitting expertise, - relationship with the ISO/TC 211 secretariat, which recently moved from Norway to Sweden. We were careful to use the def.isotc211.org<http://def.isotc211.org> domain so as not to get tangled up with iso.org<http://iso.org>. But we still have to work with the Swedes, who we don't know so well yet. Practically, there is also the matter of where the actual resources would be hosted. Is raw.githubusercontent.com/ISO-TC211/GOM/master/isotc211_GOM_harmonizedOntology/19156<http://raw.githubusercontent.com/ISO-TC211/GOM/master/isotc211_GOM_harmonizedOntology/19156> acceptable? And, while I could work with Jean to get .ttl versions put alongside, I'm not sure that anything much more sophisticated than that could be expected any time soon. > I doubt this would be helpful but we could perhaps mint new ones that did dereference and assert equivalence but that's only worth doing if it provides some functionality that's actually useful. I'd be reluctant to head that direction. As I mentioned on the call and in my documentation, URIs in the def.isotc211.org<http://def.isotc211.org> domain are specified in ISO 19150-2, so putting another façade in front is really just obfuscation. Realistically getting the def.isotc211.org<http://def.isotc211.org> URIs to dereference is likely to take months rather than weeks, but I think it is plausible, and if we are OK with using them as identifiers in the meantime then it is all defensible in the short term and there would be no discontinuity in the long. Simon -----Original Message----- From: Phil Archer [mailto:phila@w3.org<mailto:phila@w3.org>] Sent: Wednesday, 8 February, 2017 17:48 To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org> Subject: Non-dereferencable URIs (was Re: ACTION-255 - o&m alignment) I'm sorry I wasn't able to speak about this on the call. By the time this topic came up I was being driven along the road and had insufficient bandwidth to un-mute myself although I could hear the conversation. Of course dereferencable URIs are preferred over non-dereferencable ones. However, this should not be seen as an absolute requirement or diktat. If there are good reasons to use non-dereferencable URIs - and it sounded to me as if Simon was making a very strong case for their use - and if the non-dereferencable state causes no harm, then go ahead. The question is, of course, can TC211 be encouraged to make things like http://def.isotc211.org/iso19156/2011/ dereferencable? If it helps, we'd happily host the relevant data to which those URIs could redirect (I'm sure OGC and others would too of course). I doubt this would be helpful but we could perhaps mint new ones that did dereference and assert equivalence but that's only worth doing if it provides some functionality that's actually useful. Phil On 07/02/2017 22:26, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote: > I've dropped it into a Wiki page here (formatting not yet complete). > > https://www.w3.org/2015/spatial/wiki/Alignment_to_O%26M > > This should help with your namespace and prefix questions Laurent. > > From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> [mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>] > Sent: Wednesday, 8 February, 2017 08:35 > To: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org> > Subject: [ExternalEmail] RE: ACTION-255 - o&m alignment > > If you are unable to see the section in the HTML in the branch, here is the proposed text: > > ----------------------- > > 8. Alignment to Observations and Measurements > > This section introduces the alignment of SOSA/SSN to OGC Observations and Measurements [OandM] (also known as ISO 19156:2011). > > O&M is specified as a UML model, following the patterns specified in ISO 19109 Geographic Information - Rules for Application Schema [ISO-19109]. This means that the classes represent concepts from the application domain, so can be approximately equated with classes in an ontology. > > Two OWL implementations of O&M have been described: > > an explicit translation of the UML following the rules specified in > [ISO-19150-2] - see [OM-Heavy]; and a handcrafted version in more idiomatic OWL [OM-Lite]. > The following sections provide two mappings or alignments between SOSA/SSN and O&M: the first with the official ISO/OGC UML conceptual model, and the second with the lightweight OWL implementation. > > 8.1 Alignment to Observations and Measurements UML model > > This section is non-normative. > > The explicit translation generates an RDF entity for every class, class attribute, and association-role from the original O&M UML model. It comes at a cost of a large set of dependencies on similar OWL translations of other UML models from the ISO 19100 series. Nevertheless, the URI for each RDF entity is a convenient identifier to elements of the UML model. These can be used to identify the elements of O&M in a formal RDF/OWL alignment. > > Rules for generating the URIs are provided in [ISO-19150-2], and appear in the official OWL implementation of ISO 19156 (O&M) maintained by the ISO/TC 211 Group on Ontology Management. > > The following namespace prefixes are used in the alignment to SOSA. > > Prefix Namespace > sosa: http://www.w3.org/ns/sosa/ > sosa-om: http://www.w3.org/ns/sosa-om#<http://www.w3.org/ns/sosa-om> > iso19156-gfi: http://def.isotc211.org/iso19156/2011/GeneralFeatureInstance#<http://def.isotc211.org/iso19156/2011/GeneralFeatureInstance> > iso19156-om: http://def.isotc211.org/iso19156/2011/Observation#<http://def.isotc211.org/iso19156/2011/Observation> > iso19156-sf: http://def.isotc211.org/iso19156/2011/SamplingFeature#<http://def.isotc211.org/iso19156/2011/SamplingFeature> > iso19156-sfs: http://def.isotc211.org/iso19156/2011/SpatialSamplingFeature#<http://def.isotc211.org/iso19156/2011/SpatialSamplingFeature> > iso19156-sp: http://def.isotc211.org/iso19156/2011/Specimen#<http://def.isotc211.org/iso19156/2011/Specimen> > Utility classes > > Five utiity classes are defined locally to support the formalization of the alignment. > > 1. Three disjoint subclasses of sosa:Procedure: > > sosa-om:ActuationProcedure Actuation procedures or recipes > sosa-om:ObservationProcedure Observation procedures or recipes > sosa-om:SamplingProcedure Sampling, sample preparation or processing > procedures or recipes 2. Two classes related to sampling, which complement SOSA classes related to actuation and observation: > > sosa-om:SamplingDevice Sampling, sample preparation or processing devices, comparable to sosa:Actuator and sosa:Sensor > sosa-om:SamplingEvent Sampling, sample preparation or processing event or act, comparable to sosa:Actuation and sosa:Observation > Class alignments > > The primary classes from [OandM] have direct equivalents in SOSA classes supplemented by the utility classes described above, as follows: > > iso19156-om:OM_Observation equivalent class sosa:Observation > iso19156-om:OM_Process equivalent class sosa:Sensor or sosa-om:ObservationProcedure > iso19156_sf:SF_SamplingFeature equivalent class sosa:Sample > iso19156-sf:SF_Process equivalent class sosa-om:SamplingDevice or sosa-om:SamplingProcedure > Additional alignments from SOSA/SSN classes to O&M classes are as follows. > > sosa:FeatureOfInterest subclass of iso19156_gfi:GFI_DomainFeature > where iso19156_gfi:GFI_DomainFeature has the definition: > > The class GFI_DomainFeature represents 'real-world' features which are the ultimate subject of an observation campaign, i.e. the features from an application domain that are not artefacts of the observation process (sampling features). > sosa:Actuator subclass of iso19156_gfi:GFI_Feature > sosa:Platform subclass of iso19156_gfi:GFI_Feature > where iso19156_gfi:GFI_Feature has the definition > > The class GFI_Feature represents the set of all classes which are feature types. In an implementation this abstract class shall be substituted by a concrete class representing a feature type from an application schema associated with a domain of discourse (ISO 19109, ISO 19101). > Property alignments > > The following properties from [OandM] have direct equivalents in SOSA properties: > > iso19156-om:OM_Observation.featureOfInterest equivalent property sosa:hasFeatureOfInterest > iso19156-om:OM_Observation.observedProperty equivalent property sosa:observedProperty > iso19156-om:OM_Observation.phenomenonTime equivalent property sosa:phenomenonTime > iso19156-sf:SF_SamplingFeature.sampledFeature equivalent property sosa:isSampleOf > Additional alignments from O&M properties to SOSA are as follows. > > iso19156-om:OM_Observation.procedure sub-property of sosa:usedProcedure > iso19156-sp:SF_Specimen.samplingMethod sub-property of sosa:usedProcedure > These alignments are modeled as sub-properties because sosa:usedProcedure applies to actuation, observation or sampling activities. > > iso19156-om:OM_Observation.result sub-property of sosa:hasResult > iso19156-om:OM_Observation.resultTime sub-property of sosa:resultTime > iso19156-sp:SF_Specimen.samplingTime sub-property of sosa:resultTime > iso19156-sp:PreparationStep.time sub-property of sosa:resultTime > These alignments are modeled as sub-properties because sosa:hasResult and sosa:resultTime applies to actuation, observation or sampling activities. > > iso19156-sfs:SF_SpatialSamplingFeature.hostedProcedure sub-property of sosa:hosts > These alignments are modeled as a sub-property because the domain of iso19156-sfs:SF_SpatialSamplingFeature.hostedProcedure is a spatial sampling feature, such as a station, rather than a more general platform. > > An RDF file containing a graph corresponding to this alignment is available. > > 8.2 Alignment to om-lite implementation of Observations and > Measurements > > This section is non-normative. > > An idiomatic OWL implementation of O&M (including Sampling Features) is described in [OM-Lite]. > > The following namespace prefixes are used in the alignment to SOSA. > > Prefix Namespace > sosa: http://www.w3.org/ns/sosa/ > sosa-oml: http://www.w3.org/ns/sosa-oml#<http://www.w3.org/ns/sosa-oml> > oml: http://def.seegrid.csiro.au/ontology/om/om-lite#<http://def.seegrid.csiro.au/ontology/om/om-lite> > samfl: http://def.seegrid.csiro.au/ontology/om/sam-lite#<http://def.seegrid.csiro.au/ontology/om/sam-lite> > Utility classes > > Five utiity classes are defined locally to support the formalization of the alignment. > > 1. Three disjoint subclasses of sosa:Procedure: > > sosa-oml:ActuationProcedure Actuation procedures or recipes > sosa-oml:ObservationProcedure Observation procedures or recipes > sosa-oml:SamplingProcedure Sampling, sample preparation or processing > procedures or recipes 2. Two classes related to sampling, which complement SOSA classes related to actuation and observation: > > sosa-oml:SamplingDevice Sampling, sample preparation or processing devices, comparable to sosa:Actuator and sosa:Sensor > sosa-oml:SamplingEvent Sampling, sample preparation or processing event or act, comparable to sosa:Actuation and sosa:Observation > Class alignments > > The primary classes from [OM-Lite] have direct equivalents in SOSA classes supplemented by the utility classes described above, as follows: > > oml:Observation equivalent class sosa:Observation > oml:Process equivalent class sosa:Sensor or sosa-om:ObservationProcedure > samfl:SamplingFeature equivalent class sosa:Sample > samfl:Process equivalent class sosa-om:SamplingDevice or sosa-om:SamplingProcedure > Property alignments > > The following properties from [OM-Lite] have direct equivalents in SOSA properties: > > oml:featureOfInterest equivalent property sosa:hasFeatureOfInterest > oml:observedProperty equivalent property sosa:observedProperty > oml:phenomenonTime equivalent property sosa:phenomenonTime > samfl:sampledFeature equivalent property sosa:isSampleOf > Additional alignments from [OM-Lite] properties to SOSA are as follows. > > oml:procedure sub-property of sosa:usedProcedure > samfl:samplingMethod sub-property of sosa:usedProcedure > These alignments are modeled as sub-properties because sosa:usedProcedure applies to actuation, observation or sampling activities. > > oml:result sub-property of sosa:hasResult > oml:resultTime sub-property of sosa:resultTime > samfl:samplingTime sub-property of sosa:resultTime > These alignments are modeled as sub-properties because sosa:hasResult and sosa:resultTime applies to actuation, observation or sampling activities. > > samfl:hostedProcedure sub-property of sosa:hosts > These alignments are modeled as a sub-property because the domain of iso19156-sfs:SF_SpatialSamplingFeature.hostedProcedure is a spatial sampling feature, such as a station, rather than a more general platform. > > An RDF file containing a graph corresponding to this alignment is available. > > > From: Cox, Simon (L&W, Clayton) > Sent: Tuesday, 7 February, 2017 15:58 > To: 'Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>' > <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>>; > public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org><mailto:public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>> > Subject: RE: ACTION-255 - o&m alignment > > Note that this mapping is only from SOSA to O&M (and om-lite). > > I also intend to look at the mapping from 'SSN' (i.e. the vertical axiomatization/extension) of SOSA for observations and sensing through to O&M. Much of the intended alignment was captured in annotations in the original ontology, but the discussions in the last week suggest that some local-names might change else SOSA classes and properties used in place of old SSN equivalents. When this has settled down a comprehensive mapping should be formulated. > > Probably the key question arising from the work mentioned below is whether the proposal to use the URIs that are specified in the translation of the UML model to OWL, following the ISO 19150-2 rules, is acceptable. > > Pro: > > - It allows us to express the alignment formally within the idiom we are working in (OWL) > Cons: > > - The OWL version of O&M is not in itself published as a 'standard' and the URIs are not directly resolvable (yet, anyway) > > o However, as pointed out in the document, the URIs are persistent identifiers in the view of ISO, and the fact that ISO's process does not require a separate document for the OWL implementation should be OK for us > > - UML and OWL are so different in their assumptions that it is a fallacy to use the OWL implementation as representing the UML model > > I'm sure there are other arguments. My feeling is that the proposed approach balances formality and pragmatism OK. > > Simon > > From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> > [mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>] > Sent: Saturday, 28 January, 2017 21:33 > To: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org><mailto:public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>> > Subject: [ExternalEmail] ACTION-255 - o&m alignment > > In response to my ACTION-255 from last week's meeting, I have generated two RDF files containing formal alignments between SOSA and O&M. > > - sosa-om-mapping.ttl relates to the O&M UML model, and uses the Official ISO URIs from the OWL implementation prepared by the ISO/TC 211 Group on Ontology Management following the rules from ISO 19150-2 > > - sosa-oml-mapping.ttl relates to the om-lite and sam-lite OWL implementation recently published in Semantic Web Journal > > I have also prepared text for the SSN document describing these mappings - for chapter 8 in the spec. > So far the mappings only concern SOSA. > > I've pushed all this into a branch in GitHub > https://github.com/w3c/sdw/tree/simon-ssn-O%26M-alignments/ssn > and issued a pull-request https://github.com/w3c/sdw/pull/516 > > Simon > > Simon J D Cox > Research Scientist > Environmental Informatics > CSIRO Land and Water<http://www.csiro.au/Research/LWF> > > E simon.cox@csiro.au<mailto:simon.cox@csiro.au><mailto:simon.cox@csiro.au<mailto:simon.cox@csiro.au>> T +61 3 9545 2365<tel:%2803%29%209545%202365> M +61 403 302 672<tel:0403%20302%20672> > Mail: Private Bag 10, Clayton South, Vic 3169 > Visit: Central Reception, Research Way, Clayton, Vic 3168 > Deliver: Gate 3, Normanby Road, Clayton, Vic 3168 > people.csiro.au/Simon-Cox<http://people.csiro.au/Simon-Cox><http://people.csiro.au/Simon-Cox> > orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420><http://orcid.org/0000-0002-3884-3420> > researchgate.net/profile/Simon_Cox3<http://researchgate.net/profile/Simon_Cox3><https://www.researchgate.net/profi > le/Simon_Cox3> > github.com/dr-shorthair<http://github.com/dr-shorthair><https://github.com/dr-shorthair> > > PLEASE NOTE > The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. > > Please consider the environment before printing this email. > > > -- Phil Archer Data Strategist, W3C http://www.w3.org/ http://philarcher.org +44 (0)7887 767755<tel:+44%207887%20767755> @philarcher1 -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 9 February 2017 05:29:32 UTC