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

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> 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/ 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/wms version 1.3 clause C.2.
>
> [2] http://www.opengeospatial.org/standards/gml v3.2.1 clause 8.2.3.6
>
> [3] http://unitsofmeasure.org/ucum.html
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Friday, 1 July 2016 1:46 AM
> *To:* Maik Riechert <m.riechert@reading.ac.uk>; Rob Atkinson <
> rob@metalinkage.com.au>; SDW WG Public List <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>
> 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/Year which
> 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
>
>
>
>
>
>
>
>