- From: Little, Chris <chris.little@metoffice.gov.uk>
- Date: Tue, 12 Jul 2016 15:14:55 +0000
- To: Maik Riechert <m.riechert@reading.ac.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>
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