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

Maik

The 7-bit case insensitivity is almost certainly a legacy from the days of 5 bit telex. It is still less than ten years ago when the aviation community experimented with transmitting XML over rather old fashioned wires using International Telegraphic Alphabet No. 2 (5 bit).

The restriction does seem unnecessary.

Chris

-----Original Message-----
From: Maik Riechert [mailto:m.riechert@reading.ac.uk] 
Sent: Saturday, July 09, 2016 6:25 PM
To: Andrea Perego; Simon.Cox@csiro.au; j.d.blower@reading.ac.uk; rob@metalinkage.com.au; portele@interactive-instruments.de; public-sdw-wg@w3.org; l.vandenbrink@geonovum.nl
Subject: Re: Units of Measure (BP, Coverages, SSN,Time?)



Am 09.07.2016 um 16:30 schrieb Andrea Perego:
> On 09/07/2016 04:39, Simon.Cox@csiro.au wrote:
>>>  where the UCUM string doesn’t reflect common practice in notation
>> (note that it is limited to the 7-bit ASCII character set)
>>
>> Not quite. UCUM provides 3 alternatives:
>>
>> (i)Case insensitive 7-bit asci
>>
>> (ii)Case-sensitive 7-bit asci
>>
>> (iii)Full symbol.
>
> Just to note that this can be clearly seen in the XML-encoded UCUM 
> code list:
>
> http://unitsofmeasure.org/ucum-essence.xml

As far as I see only two symbol-related variants are normative, the case-sensitive and the case-insensitive symbol. The full name and print symbol are not normative (see §28,29 etc). Therefore it is limited to 7-bit. It's a shame they defined a case-insensitive version at all. 
Maybe one could enforce the case-sensitive version if this is defined as some RDF data type.

Cheers
Maik


>
> Andrea
>
>> Simon
>>
>> *From:*Jon Blower [mailto:j.d.blower@reading.ac.uk]
>> *Sent:* Friday, 8 July 2016 11:49 PM
>> *To:* Rob Atkinson <rob@metalinkage.com.au>; Clemens Portele 
>> <portele@interactive-instruments.de>; m.riechert@reading.ac.uk; 
>> public-sdw-wg@w3.org; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; 
>> Linda van den Brink <l.vandenbrink@geonovum.nl>
>> *Subject:* Re: Units of Measure (BP, Coverages, SSN,Time?)
>>
>> Hi Rob,
>>
>> Ø so we started this with people talking about the need for a full 
>> description, then the use URIs, now a proposal for a label only....
>>
>> Do you mean “label” in the sense of “human-readable only”? If so, I 
>> don’t recall seeing such a proposal. In case it’s not clear from 
>> previous posts, the UCUM string is a full **machine-readable** 
>> description of the unit, with a defined grammar. Do you believe that 
>> this is a “non-interoperable practice”, and if so can you elaborate?
>> What information is missing?
>>
>> By the way, there might be valid reasons for using a human-readable 
>> label **in addition to** the UCUM string, in cases where the UCUM 
>> string doesn’t reflect common practice in notation (note that it is 
>> limited to the 7-bit ASCII character set). So having both a label a 
>> symbol might be considered good practice, and they will often be 
>> identical in representation.
>>
>> Jon
>>
>> *From: *Rob Atkinson <rob@metalinkage.com.au 
>> <mailto:rob@metalinkage.com.au>>
>> *Date: *Friday, 8 July 2016 13:03
>> *To: *Clemens Portele <portele@interactive-instruments.de
>> <mailto:portele@interactive-instruments.de>>, Maik Riechert 
>> <m.riechert@reading.ac.uk <mailto:m.riechert@reading.ac.uk>>,
>> "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>> <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>, Rob Atkinson 
>> <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>, Jon Blower 
>> <sgs02jdb@reading.ac.uk <mailto:sgs02jdb@reading.ac.uk>>, 
>> "Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>" <simon.cox@csiro.au 
>> <mailto:simon.cox@csiro.au>>, Linda van den Brink 
>> <l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>>
>> *Subject: *Re: Units of Measure (BP, Coverages, SSN,Time?)
>>
>> OK...
>>
>>   so we started this with people talking about the need for a full 
>> description, then the use URIs, now a proposal for a label only....
>>
>> It appears the consensus is also that there is no identifiable good 
>> practice, against the range of requirements, let alone a "best" one.
>>
>> So, do we seek to demonstrate how to apply the broader set of best 
>> practices, or stay silent on the issue of how to provide further 
>> information about a particular piece of information (which is what a 
>> UoM specifier is IMHO).
>>
>> One can argue this is not a spatial problem, and therefore we cant be 
>> held to blame for non-interoperable practices proliferating.
>>
>> OTOH it is necessary to have a treatment of UoM if we are to have a 
>> useful BP for the coverages and SSN cases, and its a key use case for 
>> the Time ontology.
>>
>> On Fri, 8 Jul 2016 at 20:49 Clemens Portele 
>> <portele@interactive-instruments.de
>> <mailto:portele@interactive-instruments.de>> wrote:
>>
>>     I agree, too.
>>
>>     It also reflects the experience we have made in GML. In earlier
>>     versions of GML we required that every unit is the URI of a unit
>>     definition. However, what happened in practice was that many were
>>     using symbols like "m" instead of a URI anyway as they are shorter
>>     and often better understood (compared to
>>     http://www.opengis.net/def/uom/EPSG/0/9001). Therefore we changed
>>     this in GML 3.2 to allow symbols, too.
>>
>>     Often UCUM is used for the symbols as it seemed to be the best
>>     formalism reflecting the use of symbols in an XML attribute, but
>>     this is not a requirement as it was unclear whether this is suitable
>>     for all cases (for most cases it is) and because the UCUM long-term
>>     governance was unclear and we did not feel comfortable to make this
>>     a normative reference.
>>
>>     We added the following note: "It is recommended that the symbol be
>>     an identifier for a unit of measure as specified in the 'Unified
>>     Code of Units of Measure' (UCUM)
>>     (http://aurora.regenstrief.org/UCUM). This provides a set of symbols
>>     and a grammar for constructing identifiers for units of measure that
>>     are unique, and may be easily entered with a keyboard supporting the
>>     limited character set known as 7-bit ASCII. ISO 2955 formerly
>>     provided a specification with this scope, but was withdrawn in 2001.
>>     UCUM largely follows ISO 2955 with modifications to remove
>>     ambiguities and other problems."
>>
>>     Best regards,
>>
>>     Clemens
>>
>>     PS: The URL http://aurora.regenstrief.org/UCUM no longer works
>>     (talking about governance).
>>
>>     On 8. Juli 2016 at 10:53:26, Linda van den Brink
>>     (l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>)
>> wrote:
>>
>>         +1 to Jon’s understanding of “best practice”
>>
>>         Does someone have an example of UCUM? I haven’t come across it
>>         before.
>>
>>         *Van:*Jon Blower [mailto:j.d.blower@reading.ac.uk
>>         <mailto:j.d.blower@reading.ac.uk>]
>>         *Verzonden:* vrijdag 8 juli 2016 10:50
>>         *Aan:* Rob Atkinson; Linda van den Brink; Simon.Cox@csiro.au
>>         <mailto:Simon.Cox@csiro.au>; m.riechert@reading.ac.uk
>>         <mailto:m.riechert@reading.ac.uk>; public-sdw-wg@w3.org
>>         <mailto:public-sdw-wg@w3.org>
>>         *Onderwerp:* 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
>>         <mailto:rob@metalinkage.com.au>>
>>         *Date: *Thursday, 7 July 2016 22:56
>>         *To: *Linda van den Brink <l.vandenbrink@geonovum.nl
>>         <mailto:l.vandenbrink@geonovum.nl>>, Rob Atkinson
>>         <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>, Jon
>>         Blower <sgs02jdb@reading.ac.uk <mailto:sgs02jdb@reading.ac.uk>>,
>>         "Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>"
>>         <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>, Maik Riechert
>>         <m.riechert@reading.ac.uk <mailto:m.riechert@reading.ac.uk>>,
>>         "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>>         <public-sdw-wg@w3.org <mailto: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 <mailto: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
>>             <mailto:rob@metalinkage.com.au>]
>>             *Verzonden:* dinsdag 5 juli 2016 00:33
>>             *Aan:* Jon Blower; Simon.Cox@csiro.au
>>             <mailto:Simon.Cox@csiro.au>; rob@metalinkage.com.au
>>             <mailto:rob@metalinkage.com.au>; m.riechert@reading.ac.uk
>>             <mailto:m.riechert@reading.ac.uk>; public-sdw-wg@w3.org
>>             <mailto: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
>>             <http://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 <mailto: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 <mailto:Simon.Cox@csiro.au>"
>>                 <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>
>>                 *Date: *Monday, 4 July 2016 01:13
>>                 *To: *"rob@metalinkage.com.au
>>                 <mailto:rob@metalinkage.com.au>" <rob@metalinkage.com.au
>>                 <mailto:rob@metalinkage.com.au>>, Jon Blower
>>                 <sgs02jdb@reading.ac.uk
>>                 <mailto:sgs02jdb@reading.ac.uk>>, Maik Riechert
>>                 <m.riechert@reading.ac.uk
>>                 <mailto:m.riechert@reading.ac.uk>>,
>>                 "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>>                 <public-sdw-wg@w3.org <mailto: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
>>                 <http://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
>>                 <mailto:rob@metalinkage.com.au>]
>>                 *Sent:* Saturday, 2 July 2016 1:32 PM
>>                 *To:* Jon Blower <j.d.blower@reading.ac.uk
>>                 <mailto:j.d.blower@reading.ac.uk>>; Rob Atkinson
>>                 <rob@metalinkage.com.au
>>                 <mailto:rob@metalinkage.com.au>>; Cox, Simon (L&W,
>>                 Clayton) <Simon.Cox@csiro.au
>>                 <mailto:Simon.Cox@csiro.au>>; m.riechert@reading.ac.uk
>>                 <mailto:m.riechert@reading.ac.uk>; public-sdw-wg@w3.org
>>                 <mailto: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
>>                 <mailto: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
>>                     <mailto:rob@metalinkage.com.au>>
>>                     *Date: *Friday, 1 July 2016 14:39
>>                     *To: *Jon Blower <sgs02jdb@reading.ac.uk
>>                     <mailto:sgs02jdb@reading.ac.uk>>, Rob Atkinson
>>                     <rob@metalinkage.com.au
>>                     <mailto:rob@metalinkage.com.au>>,
>>                     "Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>"
>>                     <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>,
>>                     Maik Riechert <m.riechert@reading.ac.uk
>>                     <mailto:m.riechert@reading.ac.uk>>,
>>                     "public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>"
>>                     <public-sdw-wg@w3.org 
>> <mailto: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
>>                     <mailto: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 
>> <mailto:rob@metalinkage.com.au>>
>>                         *Date: *Friday, 1 July 2016 08:46
>>                         *To: *"Simon.Cox@csiro.au
>>                         <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au
>>                         <mailto:Simon.Cox@csiro.au>>,
>>                         "rob@metalinkage.com.au
>>                         <mailto:rob@metalinkage.com.au>"
>>                         <rob@metalinkage.com.au 
>> <mailto:rob@metalinkage.com.au>>, Maik Riechert
>>                         <m.riechert@reading.ac.uk 
>> <mailto:m.riechert@reading.ac.uk>>,
>>                         "public-sdw-wg@w3.org
>>                         <mailto:public-sdw-wg@w3.org>"
>>                         <public-sdw-wg@w3.org 
>> <mailto:public-sdw-wg@w3.org>>
>>
>>
>>                         *Subject: *Re: Units of Measure (BP, Coverages,
>>                         SSN,Time?)
>>
>>                         *Resent-From: *<public-sdw-wg@w3.org
>>                         <mailto: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
>>                         <mailto: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/ 
>> <http://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/wmsversion

>>                             1.3 clause C.2.
>>
>>                             [2]
>> http://www.opengeospatial.org/standards/gml

>>                             v3.2.1 clause 8.2.3.6 
>> <http://www.opengeospatial.org/standards/gml%20v3.2.1%20clause%208.2.

>> 3.6>
>>
>>                             [3] http://unitsofmeasure.org/ucum.html

>>
>>                             *From:*Rob Atkinson
>>                             [mailto:rob@metalinkage.com.au 
>> <mailto:rob@metalinkage.com.au>]
>>                             *Sent:* Friday, 1 July 2016 1:46 AM
>>                             *To:* Maik Riechert
>>                             <m.riechert@reading.ac.uk 
>> <mailto:m.riechert@reading.ac.uk>>; Rob
>>                             Atkinson <rob@metalinkage.com.au 
>> <mailto:rob@metalinkage.com.au>>; SDW WG
>>                             Public List <public-sdw-wg@w3.org 
>> <mailto: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 
>> <mailto: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/Yearwhich 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
>>
>

Received on Tuesday, 12 July 2016 15:15:30 UTC