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

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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>