- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Sat, 09 Jul 2016 17:30:18 +0200
- To: Simon.Cox@csiro.au, j.d.blower@reading.ac.uk, rob@metalinkage.com.au, portele@interactive-instruments.de, m.riechert@reading.ac.uk, public-sdw-wg@w3.org, l.vandenbrink@geonovum.nl
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
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
>
--
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 Saturday, 9 July 2016 15:31:27 UTC