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

It depends how and to which degree you integrate LD into something or 
expect it to be used, especially in simple web APIs. Have a look:

// http://example.com/temperature/UK/RG17SB Accept:application/json
{
   "@context": "http://example.com/myapi.context",
   "measurement": 27.5,
   "unit": {
     "label": { "en": "Degree Celsius" },
     "symbol": {
       "type": "UCUM",
       "value": "Cel"
     }
   }
}

where http://example.com/myapi.context would be:

{
   "type": "@type",
   "value": "@value",
   "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
   "qudt": "http://qudt.org/schema/qudt#",
   "skos": "http://www.w3.org/2004/02/skos/core#",
   "measurement": 
"http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasDataValue",
   "unit": "qudt:unit",
   "label": {"@id": "skos:prefLabel", "@container": "@language"},
   "symbol": "qudt:symbol",
   "UCUM": "http://www.opengis.net/def/uom/UCUM/"
}

(I used "Cel" again, since this is how you serialize °C in UCUM.)

You promise to your clients that this is a fixed structure, and that 
they don't need a JSON-LD parser if they don't want to. The use case 
could be to simply display the above measurement information on a 
webpage. And with just that, it becomes easy to test that the unit of 
the value uses the UCUM scheme, and then the client may decide to use 
the https://github.com/jmandel/ucum.js library to convert the 
temperature to any other available option for the user's convenience, 
like Fahrenheit, Kelvin, ... No LD involved here. I can't imagine doing 
the same on RDF level in that same simplicity.

All I'm saying is, don't forget the other side. RDF/LD is important, but 
for some use cases it's just irrelevant, and I don't think those cases 
should be ignored. I think those two worlds must be merged.

Cheers
Maik


Am 30.06.2016 um 16:45 schrieb Rob Atkinson:
> 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
>>
>>
>