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

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