- From: Maik Riechert <m.riechert@reading.ac.uk>
- Date: Tue, 12 Jul 2016 17:57:06 +0100
- To: "Little, Chris" <chris.little@metoffice.gov.uk>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "j.d.blower@reading.ac.uk" <j.d.blower@reading.ac.uk>, "rob@metalinkage.com.au" <rob@metalinkage.com.au>, "portele@interactive-instruments.de" <portele@interactive-instruments.de>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "l.vandenbrink@geonovum.nl" <l.vandenbrink@geonovum.nl>
Interesting, although don't forget that the case-insensitive variant
actually uses different symbols in some cases, it's not just that casing
is irrelevant there, e.g. MA instead of M for the mega-prefix. And of
course this is making clients more complex. Simple real-world example:
ucum.js only supports the case-sensitive variant
(https://github.com/jmandel/ucum.js) without actually stating it in
their documentation.
Cheers
Maik
Am 12.07.2016 um 16:14 schrieb Little, Chris:
> 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 16:57:52 UTC