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

Rob, Maik,

This thread reminds me something we discussed a couple of years ago in 
the LOCADD CG, and summarised here:

https://www.w3.org/community/locadd/wiki/LOCN_extension:_Metadata#Encoding_.2F_Representation_2

I copy-paste below the relevant text:

[[
Specifying the level of detail includes the ability to represent 
quantities and units of measure.

Discussion [1] on the LOCADD mailing list concerning Frans Knibbe's 
proposal [2], identified a few possible options:
- use literals, with a default unit of measure
- encode quantity + unit of measure in a literal (see mail [3] from 
Andrea Perego, 4 Sep 2014)
- use the GoodRelations vocabulary (see mail [4] from Bart van Leeuwen, 
5 Sep 2014)
- use the QUDT ontologies (see mail [5] from Frans Knibbe, 10 Sep 2014)
]]

I would like just to say that, IMO, the issue is about the possibility 
of specifying units of measures with URIs, or integrate them into a 
typed literal - following a syntax encoding scheme (in DC terms), as the 
ones used for time/dates and geometries.

I don't see them as mutually exclusive. Rather, I think it would be good 
to support both in order to address different use cases. Of course, also 
in this case there's the issue of which should be the reference 
specification to be used.

Andrea

----
[1]https://lists.w3.org/Archives/Public/public-locadd/2014Sep/0000.html
[2]https://www.w3.org/community/locadd/wiki/Proposal_for_extension_of_LOCN_with_properties_for_Coordinate_Reference_System_and_Level_of_Detail
[3]https://lists.w3.org/Archives/Public/public-locadd/2014Sep/0007.html
[4]https://lists.w3.org/Archives/Public/public-locadd/2014Sep/0013.html
[5]https://lists.w3.org/Archives/Public/public-locadd/2014Sep/0022.html


On 30/06/2016 17:45, Rob Atkinson wrote:
> 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/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
>>
>>
>

-- 
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

Received on Thursday, 30 June 2016 16:44:13 UTC