- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Fri, 08 Jul 2016 13:59:57 +0200
- To: Clemens Portele <portele@interactive-instruments.de>, "m.riechert@reading.ac.uk" <m.riechert@reading.ac.uk>, Rob Atkinson <rob@metalinkage.com.au>, Jon Blower <j.d.blower@reading.ac.uk>, "Simon.Cox@csiro.au" <simon.cox@csiro.au>, Linda van den Brink <l.vandenbrink@geonovum.nl>
- Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
+1 from me as well.
Andrea
On 08/07/2016 12:49, Clemens Portele 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
> <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]
>> *Verzonden:* vrijdag 8 juli 2016 10:50
>> *Aan:* Rob Atkinson; Linda van den Brink; Simon.Cox@csiro.au;
>> m.riechert@reading.ac.uk; 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
>>
>>
>>
>>
>>
>>
>>
--
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy
https://ec.europa.eu/jrc/
Received on Friday, 8 July 2016 12:00:43 UTC