Re: Non-dereferencable URIs (was Re: ACTION-255 - o&m alignment)

+1


On Thu, 9 Feb 2017 at 11:25 <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 domain so as not to get
> tangled up with 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
> 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 domain are specified in
> ISO 19150-2, so putting another façade in front is really just obfuscation.
>
> Realistically getting the 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]
> Sent: Wednesday, 8 February, 2017 17:48
> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; 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 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]
> > Sent: Wednesday, 8 February, 2017 08:35
> > To: 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#
> > iso19156-gfi:
> http://def.isotc211.org/iso19156/2011/GeneralFeatureInstance#
> > iso19156-om:  http://def.isotc211.org/iso19156/2011/Observation#
> > iso19156-sf:     http://def.isotc211.org/iso19156/2011/SamplingFeature#
> > iso19156-sfs:
> http://def.isotc211.org/iso19156/2011/SpatialSamplingFeature#
> > iso19156-sp:    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#
> > oml:     http://def.seegrid.csiro.au/ontology/om/om-lite#
> > samfl:  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'
> > <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>;
> > 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]
> > Sent: Saturday, 28 January, 2017 21:33
> > To: 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> T +61 3 9545 2365
> <(03)%209545%202365> M +61 403 302 672 <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>
> > orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420>
> > researchgate.net/profile/Simon_Cox3<https://www.researchgate.net/profi
> > le/Simon_Cox3>
> > 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 <+44%207887%20767755>
> @philarcher1
>

Received on Thursday, 9 February 2017 01:05:49 UTC