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

I see, thanks for the explanation.

On 02/08/2017 09:28 PM, Simon.Cox@csiro.au wrote:
>
> 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/
>         <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
>         <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/ <http://geog.ucsb.edu/%7Ejano/>
> Semantic Web Journal:http://www.semantic-web-journal.net


-- 
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 Thursday, 9 February 2017 05:36:17 UTC