Re: Units of Measure (BP, Coverages, SSN,Time?)

+1

I think BP to define dimensions for use in a community is justifiable.

We can then point to the desirability of a register of dimensions managed
at OGC as a recommendation for a general community concerned with spatial
interoperability...

  My project can prototype such a thing by end Sept... :-) The registry
itself will conform to the SDW BP .. and it will be available as linked
data using  RDF, Json-ld and HTML with an access API to support easy access
to support key Use Cases

if we get an extension to SDW timelines we may be able to get such a
registry under formal governance and make a stronger recommendation to use
it :-)

Rob

On Mon, 25 Jul 2016 11:58 pm Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> Hello Jeremy,
>
> Thank you very much for taking the time for writing a summary. I think it
> certainly is useful. I don't have much of an answer to the open questions,
> although I do think that the option of ignoring the problem would be bad.
> Units of measure are important for spatial data, just think about the
> difference between degrees and meters, both popular units for geometric
> data.
>
> I hope that whatever we recommend will not be something along the lines of
> "Use something that best fits the needs of the intended application" or
> "Use something that meets the need of your community or domain". I hope
> that our deliverables can help in making the web a place without
> application based or domain based silos, where data are made available in
> the best way possible, for as many uses and users as possible.
>
> I understand that the BP document can not uniquely endorse one scheme for
> UoM, just like it is difficult to recommend a single best practise for
> geometry encoding or for CRS specification. The required effort would be
> too big. But I hope that does not stop us from making meaningful progress
> towards such goals. Perhaps the BP document (or a separate note) could
> pinpoint the areas that suffer from gaps or overlap between standards and
> in some way aid the process of working towards single best standards?
> Perhaps by making the case for cooperation between the communities behind
> those standards, or by identifying clear items for further work (by
> standardization communities like the OGC and the W3C)?
>
> Regards,
> Frans
>
>
>
> On 19 July 2016 at 14:29, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>> Thanks Scott.
>>
>> I think we have the flexibility to write any [W3C] NOTEs we can
>> (resources permitting).
>>
>>
>> On Tue, 19 Jul 2016 at 13:28 Scott Simmons <ssimmons@opengeospatial.org>
>> wrote:
>>
>>> very useful, Jeremy - now I need to digest this meal! To your options on
>>> item (D), I like the idea of a separate NOTE, if that is allowed under W3C.
>>> We could make it a Discussion Paper in OGC.
>>>
>>> Scott
>>>
>>> On Jul 19, 2016, at 4:44 AM, Jeremy Tandy <jeremy.tandy@gmail.com>
>>> wrote:
>>>
>>> Hi-
>>>
>>> it's taken me quite a long time to parse through this thread (amongst
>>> other stuff too).
>>>
>>> What I think it says is:
>>>
>>> A) we most often want to refer to units of measure (UoM) using a
>>> string-literal notation; in the case of UCUM this is a microformat that
>>> follows grammatical rules
>>> B) given that we shouldn't assume clients understand the notation, we
>>> need some mechanism to inform clients what namespace the notation is from;
>>> Maik's email [1] shows how to do this within (fairly) simple JSON-LD using
>>> a Typed Literal, while GML indicates this in the data format specification (ref.
>>> ISO 19136 GML §8.2.3.6 MeasureType, UomIdentifier) ... Maik's example
>>> shows how a human developer is able to interpret the data and build an
>>> application to work with the data, but ...
>>> C) it's still not obvious how one would enable software agent to find
>>> the machine-readable definition of the UoM from the (typed) literal ...
>>> yes, we can look up the definition of the Typed Literal, but how do you
>>> tell the software agent where the definition of the specific UoM is? Could
>>> be that the Typed Literal uses rdfs:isDefinedBy to point to a resource
>>> which defines both the Typed Literal and the vocabulary of UoMs and then
>>> parse through that vocabulary to find the UoM that uses the specified
>>> notation - but this sounds like some "magic happens here" behaviour.
>>> D) assuming one can find a machine-readable definition of the UoM, there
>>> is no unanimous consensus on which is data model / ontology is best; data
>>> publishers should choose the one that best suits their community of
>>> practice, but there is no one-size fits all solution ... the email thread
>>> talks about SKOS, QUDT, UCUM; Andrea references [2] discussions on LOCADD
>>> CG that mention more; schema.org and wikidata.org have more
>>> representations ... it seems clear to me that we need to provide a
>>> mechanism that enables data users to find the definition that meets their
>>> needs? Perhaps Rob's suggestion [3] of using skos:exactMatch to reference
>>>  other definitions is workable? There are patterns in the wild (albeit not
>>> widely used) to help distinguish between different representations: "named
>>> views" from the Linked Data API and the "profile" Link Relation type (RFC
>>> 6906).
>>>
>>> I think my (A), (B) and (C) map onto to Rob's (1) (see email [4]). I
>>> propose that we define best practices around these issues.
>>>
>>> (note: UoM is not the only thing that could follow this pattern; the
>>> same issues arise for CRS/SRS which are typically identified by
>>> string-literal notation)
>>>
>>> My (D) is somewhat more complex. It feels important to me, but (i)
>>> there's no established best practice, and (ii) the scope of this issue is
>>> wider than spatial data. The options I see are:
>>> - ignore the problem
>>> - write a BP (difficult to do)
>>> - recognise this issue and provide short discussion as a note within the
>>> BP doc
>>> - recognise this issue and write a separate NOTE that we can reference
>>> from the BP doc.
>>>
>>> The last option seems best if we have the time.
>>>
>>> I think that Rob's (2) is interesting. Can we suggest convergence on a
>>> (small) set of UoM vocabularies- or should we simply say "choose the one
>>> that meets the needs of your community of practice"?
>>>
>>> Perhaps we could provide a short list of valid UoM definitions? I think
>>> that Rob has offered to do the legwork to deploy such a resource?
>>>
>>> Other things that have been mentioned but I think are out of scope:
>>> * identification of URL patterns for UoM (e.g. "/" pattern) ... DWBP has
>>> some good discussion about choice of identifiers and references to good
>>> material
>>> * in depth discussion about reasoning over UoM (etc.); I think that
>>> Maik's approach to consider the typical web developer was a good starting
>>> point, and to quote Jon [5] “*having tried to develop applications that
>>> are enabled by strongly-typed units/quantities, I’m still not quite sure
>>> what the ‘killer application’ for this capability is, apart from the case
>>> of automated unit conversion.*”   ... As Manu Sporny says [6] "I
>>> personally wanted JSON-LD to be compatible with RDF, but that's about it.";
>>> I think we need to aim for the sweet spot of enabling web-developers to be
>>> productive without forcing the whole Semantic Web construct onto people.
>>>
>>> Thoughts please.
>>>
>>> Jeremy
>>>
>>> PS: In the plenary call 2-weeks ago, we suggested that long threads like
>>> this should be summarised from time-to-time. It's taken me a while to do
>>> this (so that I can understand what I need to do as a BP editor). Have I
>>> missed the point? Is this kind of summary useful?
>>>
>>>
>>> [1]:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0165.html
>>> [2]:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jun/0166.html
>>> [3]:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0067.html
>>> [4]:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0068.html
>>> [5]:
>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/att-0065/00-part
>>>
>>> [6]: http://manu.sporny.org/2014/json-ld-origins-2/
>>>
>>> On Mon, 11 Jul 2016 at 01:55 Rob Atkinson <rob@metalinkage.com.au>
>>> wrote:
>>>
>>>>
>>>> Stepping back a little - there are multiple separate BP issues here,
>>>> 1) Generally, how to deal with the situation where we want to provide
>>>> more information about a literal value,  labels+links etc
>>>> 2) An approach to that encourages convergence on a small number of
>>>> vocabularies (covered in DWBP)
>>>> 3) How to deal with a placeholder - where there is no well-governed
>>>> option currently available but may conceivably be in the mod-term
>>>> 4) need for a specific UoM recommendation because UoM is a part of the
>>>> information models being put forward as BP
>>>> 5) existing deployment of specific content as a BP, versus identifiable
>>>> BP and and recommendation that specific content should be made available
>>>>
>>>> In addition we have existing OGC use of UoM vocabularies and a
>>>> mechanism that is not-quite-BP - but could be tweaked (i.e.
>>>> opengis.net/def/uom )
>>>>
>>>> Does it make things much easier if we deploy resources here matching
>>>> general BP recommendations ? So we dont have to say "if only someone would
>>>> do it"  Even if its just the UCUM vocab as SKOS, with basic
>>>> content-negotiation we could use it to justify the JSON-LD implementation
>>>> people weem to want, but AFAICT isnt actually available as a BP relevant to
>>>> spatial data anywhere?
>>>>
>>>> I dont mind helping to make it so - but I need to find some way to
>>>> first disentangle all the co-existing philosophies in the SDW scope and
>>>> identify a consensus position.
>>>>
>>>> Rob
>>>>
>>>> On Mon, 11 Jul 2016 at 10:15 Rob Atkinson <rob@metalinkage.com.au>
>>>> wrote:
>>>>
>>>>> could all these cases just as easily be handled using off-the-shelf
>>>>> SKOS?
>>>>>
>>>>> specialisation and generalisation = broader/narrower
>>>>> skos:notation allows us to specify that UCUM microformat is used:
>>>>> skos:notation "m/s"^^http://ucum...
>>>>> skos:exactMatch can point to any other vocabularies
>>>>>
>>>>> We can state that a literal (e.g. UCUM) string should be documented as
>>>>> matching a skos:notation element in a chosen namespace.
>>>>>
>>>>> AFAICT if we recommend (but dont mandate) SKOS as a canonical form to
>>>>> be dereferenced from a / based URI - then we only have to deal with the
>>>>> more general issue of how to provide a label for a link.
>>>>>
>>>>> content negotiation could be used to ask for an OWL class model is one
>>>>> is available - we just need a note to say this is possible to implement
>>>>> with this pattern.
>>>>>
>>>>> We can be silent on the microformat issue - thats a contract between
>>>>> the choice of namespace and the user - the machinery doesnt need to know
>>>>> what any given microformat supports.
>>>>>
>>>>> SKOS-JSON-LD rules can be sued to serialise any part we care about,
>>>>> and this is generally applicable and re-usable machinery to be defined
>>>>> elsewhere. (RDF-Datacube as suggested by the W3C DWBP uses SKOS, so any
>>>>> JSON-LD approach should be able to inherit this from a borader BP)
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 11 Jul 2016 at 08:49 <Simon.Cox@csiro.au> wrote:
>>>>>
>>>>>> Ø  Sure, understood. A concrete use case would be helpful if you
>>>>>> have one?
>>>>>>
>>>>>>
>>>>>>
>>>>>> The cases I’ve encountered are primarily during discovery.
>>>>>>
>>>>>> QUDT has :generalization and :specialization properties, so this
>>>>>> allows you to traverse up and down hierarchies.
>>>>>>
>>>>>> For example, ‘heavy metal concentration’ might be specialized into
>>>>>> ‘lead concentration’, ‘cadmium concentration’, ‘arsenic concentration’,
>>>>>> ‘mercury concentration’, so your discovery strategy might involve asking
>>>>>> for ‘lead concentration or generalizations’, or more likely ‘heavy metal
>>>>>> concentration and all specializations’.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Jon Blower [mailto:j.d.blower@reading.ac.uk]
>>>>>> *Sent:* Monday, 11 July 2016 1:26 AM
>>>>>> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>;
>>>>>> rob@metalinkage.com.au; l.vandenbrink@geonovum.nl;
>>>>>> m.riechert@reading.ac.uk; public-sdw-wg@w3.org
>>>>>>
>>>>>>
>>>>>> *Subject:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ø  Most reasoning applications would be over on the quantity-kind
>>>>>> side
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure, understood. A concrete use case would be helpful if you have
>>>>>> one?
>>>>>>
>>>>>>
>>>>>>
>>>>>> By the way, jscience did this sort of thing in the Java world a
>>>>>> number of years ago. At one point it looked like this library might make it
>>>>>> into the core Java API (JSR-275) but the proposal was rejected. I’m not
>>>>>> entirely sure why – perhaps the problem was felt to be too complex. But
>>>>>> having tried to develop applications that are enabled by strongly-typed
>>>>>> units/quantities, I’m still not quite sure what the “killer application”
>>>>>> for this capability is, apart from the case of automated unit conversion.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>
>>>>>> *Date: *Saturday, 9 July 2016 03:39
>>>>>> *To: *Jon Blower <sgs02jdb@reading.ac.uk>, "rob@metalinkage.com.au" <
>>>>>> rob@metalinkage.com.au>, "l.vandenbrink@geonovum.nl" <
>>>>>> l.vandenbrink@geonovum.nl>, Maik Riechert <m.riechert@reading.ac.uk>,
>>>>>> "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>>>>>> *Subject: *RE: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ø  Maybe the QUDT ontology is useful, but personally I’m struggling
>>>>>> to think of a practical use case where I’d want to use this ontology for
>>>>>> any kind of reasoning.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What QUDT provides is full linkage between unit of measure and
>>>>>> quantity-kind. Most reasoning applications would be over on the
>>>>>> quantity-kind side, while the unit-of-measure side would support arithmetic
>>>>>> conversions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Jon Blower [mailto:j.d.blower@reading.ac.uk
>>>>>> <j.d.blower@reading.ac.uk>]
>>>>>> *Sent:* Friday, 8 July 2016 6:50 PM
>>>>>> *To:* Rob Atkinson <rob@metalinkage.com.au>; Linda van den Brink <
>>>>>> l.vandenbrink@geonovum.nl>; Cox, Simon (L&W, Clayton) <
>>>>>> Simon.Cox@csiro.au>; m.riechert@reading.ac.uk; public-sdw-wg@w3.org
>>>>>> *Subject:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ø  I think however that this is another example where no practice
>>>>>> could be recommended that does not include model/profile negotiation
>>>>>>
>>>>>>
>>>>>>
>>>>>> Does a BP really need to be as complicated as this? My understanding
>>>>>> of “best practice” is “the best we can realistically do at the moment”, not
>>>>>> imagining an idealised scenario that still needs a lot of thinking and
>>>>>> discussion.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As an application developer, all I really need is a unit string, plus
>>>>>> some information about how to interpret that string (e.g. an indication
>>>>>> that the string is derived from the UCUM or UDUNITS grammar). A URI for the
>>>>>> unit can also work in simple cases, but in the case of a complex unit I’d
>>>>>> much rather have the UCUM string. Maybe the QUDT ontology is useful, but
>>>>>> personally I’m struggling to think of a practical use case where I’d want
>>>>>> to use this ontology for any kind of reasoning.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we really want to propose some new approach, I’d like to see the
>>>>>> BP explicitly separate “current best practice” from “what could be possible
>>>>>> in future”, otherwise the BP document isn’t as helpful as it could be for
>>>>>> practitioners.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Rob Atkinson <rob@metalinkage.com.au>
>>>>>> *Date: *Thursday, 7 July 2016 22:56
>>>>>> *To: *Linda van den Brink <l.vandenbrink@geonovum.nl>, Rob Atkinson <
>>>>>> rob@metalinkage.com.au>, Jon Blower <sgs02jdb@reading.ac.uk>, "
>>>>>> Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Maik Riechert <
>>>>>> m.riechert@reading.ac.uk>, "public-sdw-wg@w3.org" <
>>>>>> public-sdw-wg@w3.org>
>>>>>> *Subject: *Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'll put the conversation into this format. I'll put some
>>>>>> placeholders for volunteers to put in worked examples of what they think
>>>>>> are BP implementations and important and illustrative exemplar cases.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think however that this is another example where no practice could
>>>>>> be recommended that does not include model/profile negotiation (distinct
>>>>>> from content-negotation which has been given a very narrow scope).  The
>>>>>> reason is that there is no perfect, well governed and agreed model or list
>>>>>> of possible units (two separate requirements) and that both need to
>>>>>> co-exist - so any practice has to build in the mechanism to either migrate
>>>>>> to  an emerging standard or to allow support for multiple competing
>>>>>> solutions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Or put it another way - all the incredibly hard problems around
>>>>>> different UoM systems and finding a BP recomendation are simplified by a BP
>>>>>> that allows for content models. If we are going to have a general statement
>>>>>> about this in the wider BP, the UoM case can reference it. We dont need to
>>>>>> overspecify the mechanism here - but warning people that such a capability
>>>>>> is a longer term requirement can usefully guide implementation.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 8 Jul 2016 at 00:14 Linda van den Brink <
>>>>>> l.vandenbrink@geonovum.nl> wrote:
>>>>>>
>>>>>> Hi – just trying to get through the SDW email.
>>>>>>
>>>>>>
>>>>>>
>>>>>> When I apply the template we use in the BP it would be like this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Name of the BP: **Use a URI identifier for UoM** (or a bit better
>>>>>> worded)
>>>>>>
>>>>>> **why** … a problem description I could probably get somewhere from
>>>>>> this thread
>>>>>>
>>>>>> **Intended Outcome** data user can look up the URI and get
>>>>>> information about  the UoM
>>>>>>
>>>>>> **possible approach to implementation** recommended representations
>>>>>> include QUDT, SKOS, UCUM, OWL-class?, any standard relevant to the
>>>>>> community of practice.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would very much appreciate it if starters of threads would make
>>>>>> summaries like the above…
>>>>>>
>>>>>>
>>>>>>
>>>>>> Content negotiation is a neat subject but not specific to spatial.. I
>>>>>> don’t think we should tackle this problem in the BP, or am I missing
>>>>>> something?.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Van:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>>>>>> *Verzonden:* dinsdag 5 juli 2016 00:33
>>>>>> *Aan:* Jon Blower; Simon.Cox@csiro.au; rob@metalinkage.com.au;
>>>>>> m.riechert@reading.ac.uk; public-sdw-wg@w3.org
>>>>>> *Onderwerp:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for the insights Simon.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It will take some care to turn this into a best practice recipe that
>>>>>> doesnt get broken immediately IMHO.
>>>>>>
>>>>>> We can get out of jail from an engineering perspective by saying you
>>>>>> should use a URI identifier for UoM that allows content-negotiation to
>>>>>> access one or more representations.
>>>>>>
>>>>>> Recommended representations include:
>>>>>>
>>>>>> 1) QUDT structural description
>>>>>>
>>>>>> 2) SKOS as a canonical means to describe labels and provide links to
>>>>>> alternative codes
>>>>>>
>>>>>> 3) UCUM specification if relevant for the UoM
>>>>>>
>>>>>> 4) OWL-class ?
>>>>>>
>>>>>> 4) Any representations defined by standards organisations relevant to
>>>>>> the community of practice
>>>>>>
>>>>>>
>>>>>>
>>>>>> (Content negotiation can be driven by MIME-type in headers or by
>>>>>> explicit view parameters - need a separate BP around this that encompasses
>>>>>> the UK and other LDA examples - its a pattern that generally allows us to
>>>>>> take on a de-facto option and migrate to a de jure standard when it evolves
>>>>>> - which we see as the most common pattern just about everywhere.  We also
>>>>>> either need to specify a set of views and their corresponding OWL models ,
>>>>>> or a way to bind any view to its relevant OWL model in a general way )
>>>>>>
>>>>>>
>>>>>>
>>>>>> We can further recommend the UCUM URI structure.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If necessary we can deploy such representations - I dont mind taking
>>>>>> on the deploying using the URI redirection machinery I have deployed at
>>>>>> resources.opengeospatial.org. Would prefer someone to provide some
>>>>>> endorsed representations - HTML, JSON-LD, RDF  - for QUDT, SKOS and
>>>>>> OWL-class.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Minimum would be for some examples (simple, derived-with UCUM equiv,
>>>>>> derived-without UCUM equiv). A complete set would be just as easy to deploy.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 4 Jul 2016 at 19:23 Jon Blower <j.d.blower@reading.ac.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Ø  Ideally we would have a reliable set of URIs for UOMs which could
>>>>>> leverage the UCUM algorithm to build the URI, and which would resolve to a
>>>>>> QUDT-based representation of the unit of measure.
>>>>>>
>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is it possible to use the UCUM symbol for the UoM the URI suffix? Or
>>>>>> are there problems like character-encoding issues?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>
>>>>>> *Date: *Monday, 4 July 2016 01:13
>>>>>> *To: *"rob@metalinkage.com.au" <rob@metalinkage.com.au>, Jon Blower <
>>>>>> sgs02jdb@reading.ac.uk>, Maik Riechert <m.riechert@reading.ac.uk>, "
>>>>>> public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
>>>>>> *Subject: *RE: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lets be clear about what QUDT and UCUM actually offer.
>>>>>>
>>>>>>
>>>>>>
>>>>>> QUDT -
>>>>>>
>>>>>> ·         primarily provides a model for descriptions of units of
>>>>>> measure, and of quantity-kinds (a.k.a. qualities, or “observable
>>>>>> properties”); the model is formalized using OWL, and thus provides an
>>>>>> RDF-based syntax for description of a uom or a quantity-kind
>>>>>>
>>>>>> ·         also provides some lists (called ‘vocabularies’) of
>>>>>> individual unit- and quantity-kind- descriptions, but which is very
>>>>>> idiosyncratic and incomplete (includes a whole bunch of currencies!)
>>>>>>
>>>>>> ·         there are no rules for how the labels or symbols for units
>>>>>> are built in the QUDT vocabularies; they are not aligned with the ISO or SI
>>>>>> standards (e.g. the label for the unit of length is spelled ‘Meter’, and
>>>>>> the symbol for the unit of temperature is ‘degC’), capitalization is
>>>>>> inconsistent, and use of non-asci character set is variable
>>>>>>
>>>>>> ·         the maintenance arrangements for QUDT are private
>>>>>> (TopQuadrant +  NASA) and the publication arrangements are flaky (QUDT v2.0
>>>>>> has been ‘on the way’ for about 3 years, and even though it is linked the
>>>>>> qudt.org website, it has been 404 for over a year).
>>>>>>
>>>>>>
>>>>>>
>>>>>> UCUM –
>>>>>>
>>>>>> ·         Focuses on a rule for how to generate a symbol for a
>>>>>> ‘derived uom’
>>>>>>
>>>>>> ·         uses a rigorous algorithm based on a theory of quantities
>>>>>> and dimensional analysis, which starts from any base set of units in a
>>>>>> rational system (SI, MKS, cgs, even pounds-feet-seconds if you want!)
>>>>>>
>>>>>> ·         UCUM provides a base set of symbols corresponding
>>>>>> essentially with SI, plus symbols for the standard power of ten prefixes
>>>>>> (micro/milli/kilo/mega etc). The base set has some fudging to get around
>>>>>> the anomaly that the SI base unit for mass (kg) already has a power-of-ten
>>>>>> prefix built in.
>>>>>>
>>>>>> ·         The algorithm and base set of symbols is such that symbols
>>>>>> generated following UCUM are aligned with conventional usage, and with ISO
>>>>>> 1000
>>>>>>
>>>>>> ·          There is some additional notation using {} and [] to
>>>>>> allow for annotations and ‘conventional’ units, which I always get confused
>>>>>> about.
>>>>>>
>>>>>>
>>>>>>
>>>>>> My assessment is that the QUDT Ontology v1.1 is good enough, (I was
>>>>>> on an Ontolog telecon with Pat Hayes, Ralph Hodgson, Gary Berg-Cross a
>>>>>> couple of years ago where that was the clear consensus) but the QUDT
>>>>>> vocabularies are not. So we need another set of URIs denoting uoms, with
>>>>>> the expectation that dereferencing one of these would result in a
>>>>>> QUDT-based representation.
>>>>>>
>>>>>> Ideally we would have a reliable set of URIs for UOMs which could
>>>>>> leverage the UCUM algorithm to build the URI, and which would resolve to a
>>>>>> QUDT-based representation of the unit of measure. These representations
>>>>>> should be built on-the-fly using the UCUM engine.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that, using QUDT, a uom description is an OWL _*individual*_
>>>>>> (not a class), but with complete semantics, still supporting some
>>>>>> reasoning. Rob – going with individuals doesn’t mean you have to us SKOS
>>>>>> and certainly doesn’t lose semantic precision -  probably best not to
>>>>>> casually suggest that!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>>>>>> *Sent:* Saturday, 2 July 2016 1:32 PM
>>>>>> *To:* Jon Blower <j.d.blower@reading.ac.uk>; Rob Atkinson <
>>>>>> rob@metalinkage.com.au>; Cox, Simon (L&W, Clayton) <
>>>>>> Simon.Cox@csiro.au>; m.riechert@reading.ac.uk; public-sdw-wg@w3.org
>>>>>> *Subject:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>> The encoding scheme issue raises a duality between class and instance
>>>>>> - any UoM could be expressed as as either an instance (with SKOS encoding
>>>>>> as a natural default) or a Class - RDFS or OWL being the default options.
>>>>>> In addition a meta-model of UoM could be defined in RDFS or OWL and used to
>>>>>> drive encodings of instances.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally, I think that in the Web we should specify that a URI is
>>>>>> used if one is available - and that an encoding of its details may be used
>>>>>> as annotation. In the case of an "anonymous" UoM, then the encoding will
>>>>>> still probably need to reference base units using URIs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The wrinkles are whether URIs are explicit, or encoded as items in a
>>>>>> namespace - and whether any encoding scheme (model) may be used or one is
>>>>>> recommended, and if the model itself needs to be explicitly referenced
>>>>>> (presumably this applies to JSON-LD, RDFA etc as RDF will always use URIs
>>>>>> to specify the model elements anyways.
>>>>>>
>>>>>>
>>>>>>
>>>>>> A worked example set with:
>>>>>>
>>>>>> 1) just URI from a well-known vocabulary (UCUM)
>>>>>>
>>>>>> 2) A encoded UoM with one URI, and a simple label
>>>>>>
>>>>>> 3) ditto, with a more complex set of details
>>>>>>
>>>>>> 4) ditto with more that one URI (e.g. UCUM and QUDT)
>>>>>>
>>>>>> 5) a blank/anonymous encoded UoM with base measures.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Would we go so far as to recommend QUDT as the meta-model (as per
>>>>>> example provided?) - or simply list a few in use and provide a couple of
>>>>>> examples?
>>>>>>
>>>>>>
>>>>>>
>>>>>> This will cover the "follow-your-nose" cases - however there is the
>>>>>> case of a data encoding where the UoM is specified in metadata. The
>>>>>> question here then is defining a BP for this metadata.
>>>>>>
>>>>>> One option - we can use RDF-QB to define data structures and relevant
>>>>>> UoM. I'm not sure there is an obvious alternative to ad-hoc metadata models
>>>>>> and UoM specified any non-interoperable way that emerges.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This option then speaks directly to the coverages metadata
>>>>>> perspective (encoding of data using RD-QB becomes a trivial case - we
>>>>>> simply state that if RDF encoding, then BP would be to use RDF-QB encoding
>>>>>> consistent with the RDF-QB metadata for the set, and the interesting and
>>>>>> more generally useful case is describing an existing or compact encoding
>>>>>> usefully)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, 2 Jul 2016 at 02:20 Jon Blower <j.d.blower@reading.ac.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Rob – yes, I think those are the missing bits, but, just to
>>>>>> reiterate, it may not be (just) a “vocabulary” that we need (in the sense
>>>>>> of a set of URIs), but a serialisation scheme for any unit.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For concrete examples, we should look at where we need to use units.
>>>>>> I think we have:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1.       As part of coordinate systems and coordinate reference
>>>>>> systems
>>>>>>
>>>>>> 2.       As part of measured quantities (e.g. the range of a
>>>>>> coverage), linked to observed properties etc
>>>>>>
>>>>>> 3.       …
>>>>>>
>>>>>>
>>>>>>
>>>>>> My last paragraph wasn’t very clear, sorry. I was trying to say that
>>>>>> the different uses (coordinate systems, observed properties) might actually
>>>>>> have different best practices in terms of the encoding of their units. We
>>>>>> could feasibly decide that coordinate system units are best expressed as
>>>>>> URIs, but the units of observed properties are better expressed as strings
>>>>>> in a named serialisation scheme (like UCUM). Maybe, I don’t know – just
>>>>>> raising the possibility.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Rob Atkinson <rob@metalinkage.com.au>
>>>>>> *Date: *Friday, 1 July 2016 14:39
>>>>>> *To: *Jon Blower <sgs02jdb@reading.ac.uk>, Rob Atkinson <
>>>>>> rob@metalinkage.com.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>,
>>>>>> Maik Riechert <m.riechert@reading.ac.uk>, "public-sdw-wg@w3.org" <
>>>>>> public-sdw-wg@w3.org>
>>>>>>
>>>>>>
>>>>>> *Subject: *Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is the type of recommendation i think we need. Lets refine...
>>>>>> the missing bits are:
>>>>>> 1 guidance on what vocabulary.. even noting that different
>>>>>> communities use different ones and naming them is a help.
>>>>>> 2 provision of mappings if you want to interoperate across community
>>>>>> choice here.. do you embed multiple uris, or provide sone sort of sameAs
>>>>>> service?
>>>>>> 3 concrete examples
>>>>>>
>>>>>> I dont quite follow the final paragraph and the implications for what
>>>>>> the encoding would look like?
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 1 Jul 2016 11:12 am Jon Blower <j.d.blower@reading.ac.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Just to add a little to this – units of measure are very tricky in
>>>>>> general. The overall requirement, I think, is to have an unambiguous
>>>>>> serialisation scheme for units, including both base units (the easy cases)
>>>>>> and the infinite number of derived units (the hard cases) – that is to say,
>>>>>> a spec for serialising units to ASCII strings. This allows clients to
>>>>>> convert between units, which is a primary use case for having “strongly
>>>>>> typed” units.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In terms of serialisations, I’m aware of UCUM and UDUNITS (the latter
>>>>>> is used extensively in climate/met/ocean and is connected with CF). I don’t
>>>>>> think either are perfect in terms of governance, and I’m not even sure that
>>>>>> UDUNITS has a formal spec.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Then there are URIs. QUDT has URIs for a lot of base and derived
>>>>>> units, but it can’t possibly have them all, hence the need for a scheme
>>>>>> that allows any unit to be serialised. So there will always be gaps, but I
>>>>>> note that QUDT covers a lot of the common cases I can think of – so it’s
>>>>>> not clear to me how important the gaps are.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Typical clients will just want to display the symbol for the unit, so
>>>>>> we should make sure that, if we use URIs, we also transmit the symbol, as I
>>>>>> doubt that a typical web client will want to resolve the URI and look up
>>>>>> the symbol. This is effectively what Maik is doing, by transmitting the
>>>>>> symbol plus a URI for the unit **scheme** rather than a URI for the
>>>>>> unit itself.
>>>>>>
>>>>>>
>>>>>>
>>>>>> (Question – does QUDT use UCUM as a means of generating the unit
>>>>>> symbol?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> There are a few tricky cases in science – e.g. salinity, which
>>>>>> strictly has no units and is a very weird kind of quantity – and sometimes
>>>>>> these tricky cases lead to poor practice in real data files – i.e.
>>>>>> expressing units incorrectly or inconsistently. (and of course, poor
>>>>>> practice can happen in real-world data files anywhere).
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think an overall BP recommendation would be:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1.       Express units unambiguously if possible, using a named unit
>>>>>> serialisation scheme or URI.
>>>>>>
>>>>>> 2.       Give the unit symbol, and perhaps a longer explanatory text
>>>>>> string (e.g. a rdfs:label), to help simple clients understand the unit,
>>>>>> even if they don’t want to resolve the full unit description.
>>>>>>
>>>>>> 3.       Also allow users to record “ad hoc” unit strings for
>>>>>> fallback cases that don’t fit well with existing serialisation or URI
>>>>>> schemes, making it clear that these are not really machine-understandable
>>>>>>
>>>>>>
>>>>>>
>>>>>> There may be cases where we can refine this further depending on the
>>>>>> use case. For example, in CRS definitions, which tend to use simple units,
>>>>>> it’s probably desirable to use well-known URIs to represent units. For
>>>>>> recording the units of a measured quantity (e.g. the range of the
>>>>>> coverage), I like methods like the one Maik suggested, as this maps more
>>>>>> neatly to common practice in my community.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Rob Atkinson <rob@metalinkage.com.au>
>>>>>> *Date: *Friday, 1 July 2016 08:46
>>>>>> *To: *"Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "
>>>>>> rob@metalinkage.com.au" <rob@metalinkage.com.au>, Maik Riechert <
>>>>>> m.riechert@reading.ac.uk>, "public-sdw-wg@w3.org" <
>>>>>> public-sdw-wg@w3.org>
>>>>>>
>>>>>>
>>>>>> *Subject: *Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>> *Resent-From: *<public-sdw-wg@w3.org>
>>>>>> *Resent-Date: *Friday, 1 July 2016 08:47
>>>>>>
>>>>>>
>>>>>>
>>>>>> Perfect Simon - thanks.
>>>>>>
>>>>>> Its not that obvious trawling the docs what the pragmatic aspects are.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So I would suggest then that a BP endorsed by OGC would have a
>>>>>> minimum requirement that a mapping to UCUM is provided for any vocabulary
>>>>>> used for UoM, to provide for compatibility with existing recommendations
>>>>>> (can we call these BP?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> If it helps I could set up a OGC resource for UCUM - with redirects
>>>>>> for specific terms - instead of to the containing spec (thats the way UCUM
>>>>>> works) - or to a SKOS resource with skos:exactMatch relationships to the
>>>>>> UCUM terms.  I can also deploy a crosswalk to UCUM from another UoM vocab
>>>>>> if we decide to recommend it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The onoging governance of such a resource in the context of the BP
>>>>>> can be taken up as a action from the SDW to the OGC (what is the
>>>>>> appropriate point of contact here? NA, OAB, TC, PC?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 1 Jul 2016 at 16:10 <Simon.Cox@csiro.au> wrote:
>>>>>>
>>>>>> Ø  If OGC has adopted UCUM as a BP (can someone make a definitive
>>>>>> statement on this …
>>>>>>
>>>>>>
>>>>>>
>>>>>> OGC’s endorsement of UCUM comes from
>>>>>>
>>>>>> 1.      It is recommended in WMS [1]
>>>>>>
>>>>>> 2.      Ditto GML [2]
>>>>>>
>>>>>> 3.      There is a branch of the www.opengis.net/def/ URI set for
>>>>>> UCUM - http://www.opengis.net/def/uom/UCUM/ but just redirects to
>>>>>> the UCUM spec [3]
>>>>>>
>>>>>>
>>>>>>
>>>>>> But that is purely pragmatic, as it seemed to be the best thing
>>>>>> around at the time.
>>>>>>
>>>>>> It has a fragile governance arrangement, and URIs are not
>>>>>> de-referenceable.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] http://www.opengeospatial.org/standards/wms version 1.3 clause
>>>>>> C.2.
>>>>>>
>>>>>> [2] http://www.opengeospatial.org/standards/gml v3.2.1 clause 8.2.3.6
>>>>>>
>>>>>> [3] http://unitsofmeasure.org/ucum.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
>>>>>> *Sent:* Friday, 1 July 2016 1:46 AM
>>>>>> *To:* Maik Riechert <m.riechert@reading.ac.uk>; Rob Atkinson <
>>>>>> rob@metalinkage.com.au>; SDW WG Public List <public-sdw-wg@w3.org>
>>>>>> *Subject:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks Maik,
>>>>>>
>>>>>>
>>>>>>
>>>>>> If i read this right, this example assumes the client understands
>>>>>> qudt - then uses the semantics of qudt:symbol to map instances (Cel)  in
>>>>>> another namespace to this.  UCUM uses
>>>>>> http://purl.oclc.org/NET/muo/ucum/unit/temperature/degree-Celsius as
>>>>>> the id - but the information to map to that is not present. Is "Cel" just a
>>>>>> dummy example - would you actually want to say "degree-Celsius" - and in
>>>>>> turn want the OGC redirect to respect that and redirect
>>>>>>
>>>>>> http://www.opengis.net/def/uom/UCUM/degree-Celsius to
>>>>>> http://purl.oclc.org/NET/muo/ucum/unit/temperature/degree-Celsius?
>>>>>>
>>>>>>
>>>>>>
>>>>>> What about the original assumption of using QUDT - why not use UCUM
>>>>>> or another in the first instance. Coming from the outside and trying to
>>>>>> identify a best practice, what exactly is this example saying?
>>>>>>
>>>>>>
>>>>>>
>>>>>> If OGC has adopted UCUM as a BP (can someone make a definitive
>>>>>> statement on this - it should be present in the BP when we talk about
>>>>>> vocabulary re-use - a list of vocabularies in use in the OGC space) then we
>>>>>> should start with that perhaps? If we are saying the BP requirement is to
>>>>>> allow an emerging body of QUDT usage to interoperate then we need perhaps
>>>>>> to recommend publishing the mappings as a resource - whatever we think is
>>>>>> BP we need to communicate clearly to the average user who wont have years
>>>>>> of exposure to the history and details to draw on - and will most likely
>>>>>> simply want to maximise interoperability of a few cases.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 1 Jul 2016 at 01:00 Maik Riechert <m.riechert@reading.ac.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> I just wanted to throw in a slightly different/complementary view on
>>>>>> this.
>>>>>>
>>>>>> While it is useful to have URIs for any kind of unit, I think it is
>>>>>> even more useful to have a symbolic coding in a certain coding scheme for
>>>>>> those units, because then clients with support for that scheme can easily
>>>>>> parse the unit, and transform it and the associated numbers. One scheme
>>>>>> example is UCUM (http://unitsofmeasure.org/ucum.html). OGC gave it a
>>>>>> URI as well: http://www.opengis.net/def/uom/UCUM/
>>>>>>
>>>>>> In my opinion you would have something like that (JSON-LD):
>>>>>>
>>>>>> {
>>>>>>   "@context": {
>>>>>>     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns>,
>>>>>>     "qudt": "http://qudt.org/schema/qudt#"
>>>>>> <http://qudt.org/schema/qudt>,
>>>>>>     "skos": "http://www.w3.org/2004/02/skos/core#"
>>>>>> <http://www.w3.org/2004/02/skos/core>
>>>>>>   },
>>>>>>   "rdf:value": 27.5, // for example purposes only
>>>>>>   "qudt:unit": {
>>>>>>     "@id": "qudt:DegreeCelsius",
>>>>>>     "skos:prefLabel": { "en": "Degree Celsius" },
>>>>>>     "qudt:symbol": {
>>>>>>       "@type": "http://www.opengis.net/def/uom/UCUM/"
>>>>>> <http://www.opengis.net/def/uom/UCUM/>,
>>>>>>       "@value": "Cel"
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> So the main point is that the value of "qudt:symbol" has a custom
>>>>>> data type, in this case http://www.opengis.net/def/uom/UCUM/.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>> Maik
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 30.06.2016 um 15:14 schrieb Rob Atkinson:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm looking into the BP aspects around defining data dimensions as a
>>>>>> framework for evaluating and contributing to various SDW threads. One which
>>>>>> seems to cut across, but I havent seen an explicit treatment of the UoM
>>>>>> problem. I know I may have missed previous conversatiosn - but I dont see
>>>>>> any treatment in the current reviewable docs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Specifically, if I was to follow the W3C Data on the Web Best
>>>>>> Practices I would be led via BP #2
>>>>>>
>>>>>>
>>>>>>
>>>>>> "To express frequency of update an instance from the Content-Oriented
>>>>>> Guidelines developed as part of the W3C Data Cube Vocabulary efforts was
>>>>>> used."
>>>>>>
>>>>>>
>>>>>>
>>>>>> to this statement:
>>>>>>
>>>>>> "To express the value of this attribute we would typically use a
>>>>>> common thesaurus of units of measure. For the sake of this simple example
>>>>>> we will use the DBpedia resource http://dbpedia.org/resource/Year
>>>>>> which corresponds to the topic of the Wikipedia page on "Years".
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we have a Time ontology - surely we would be pointing to that as a
>>>>>> recommendation for temporal units of measure.
>>>>>>
>>>>>> Likewise, i would have thought that OGC would have an interest in
>>>>>> binding CRS with their in built units of measure to spatial dimensions.
>>>>>>
>>>>>> One could argue that without interoperability at this level there is
>>>>>> a question why the OGC would have any involvement in Web standards - but if
>>>>>> there is a counter-argument then I feel this needs to be front-and-centre
>>>>>> of the BP to explain to a potential user what they can expect, and where
>>>>>> they are going to be left with making all the significant decisions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we have Time and CRS UoM, then we may be able to get away with not
>>>>>> specifiying a vocabulary for other UoM for measurements. Are there any
>>>>>> obvious dimensions that need UoM vocabularies?
>>>>>>
>>>>>>
>>>>>>
>>>>>> When I specify O&M profiles, (my driving use case), I'll need to
>>>>>> specify the UoM for measurements - is there any recommendation regarding
>>>>>> which vocabulary to choose?   And for CRS based dimensions?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Rob Atkinson
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>