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

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