Re: URIs / Ontology for Physical Units and Quantities

To followup with OT, I would then want to use CSVW (then possibly W3C Data
Cubes) with said unit codes and datatypes for each column.

CSVW is a bit further along now:

CSV <https://wrdrd.com/docs/consulting/knowledge-engineering#csv>
> Wikipedia: https://en.wikipedia.org/wiki/Comma-separated_values
> Standard: https://tools.ietf.org/html/rfc4180
> Extension: .csv
> MIME Type: text/csv
>
> CSV (*Comma Separated Values*) as a flat file representation for columnar
> data with rows and columns.
>
> Most spreadsheet tools can export (raw and computed) data from a sheet
> into a CSV file, for use with many other tools.
> CSVW <https://wrdrd.com/docs/consulting/knowledge-engineering#csvw>
> Homepage: https://w3c.github.io/csvw/
> Standard: http://www.w3.org/TR/tabular-data-model/
> Standard: http://www.w3.org/TR/tabular-metadata/
> Standard: http://www.w3.org/TR/csv2json/
> Standard: http://www.w3.org/TR/csv2rdf/
> Namespace: http://www.w3.org/ns/csvw#
> xmlns: @prefix csvw: <http://www.w3.org/ns/csvw#> .
> @context: http://www.w3.org/ns/csvw.jsonld
>
> CSVW (*CSV on the Web*) is a set of relatively new standards for
> representing *CSV*
> <https://wrdrd.com/docs/consulting/knowledge-engineering#csv> rows and
> columns as *RDF*
> <https://wrdrd.com/docs/consulting/knowledge-engineering#rdf> (and *JSON*
> <https://wrdrd.com/docs/consulting/knowledge-engineering#json>/ *JSON-LD*
> <https://wrdrd.com/docs/consulting/knowledge-engineering#json-ld>) along
> with *metadata*.
>
>    - URIs for datatypes (*XSD*
>    <https://wrdrd.com/docs/consulting/knowledge-engineering#xsd>, ...)
>    - URIs for columns (*RDF*
>    <https://wrdrd.com/docs/consulting/knowledge-engineering#rdf>)
>    - Document Metadata
>    - *CSV* <https://wrdrd.com/docs/consulting/knowledge-engineering#csv>
>     -> *JSON*
>    <https://wrdrd.com/docs/consulting/knowledge-engineering#json> ( ->
>    *JSON-LD*
>    <https://wrdrd.com/docs/consulting/knowledge-engineering#json-ld> ->
>    *RDF* <https://wrdrd.com/docs/consulting/knowledge-engineering#rdf> )
>    - *CSV* <https://wrdrd.com/docs/consulting/knowledge-engineering#csv>
>     -> *RDF* <https://wrdrd.com/docs/consulting/knowledge-engineering#rdf>
>    -
>
>
On Thu, May 7, 2015 at 9:49 AM, Wes Turner <wes.turner@gmail.com> wrote:

> Note also that, for durations of time, schema:duration (range
> schema:Duration) specifies "(use ISO 8601 duration format
> <http://en.wikipedia.org/wiki/ISO_8601>)."
>
> http://schema.org/Duration
> https://wrdrd.com/docs/consulting/knowledge-engineering#iso8601
>
> ISO8601 <https://wrdrd.com/docs/consulting/knowledge-engineering#iso8601>
>> Wikipedia: https://en.wikipedia.org/wiki/ISO_8601
>> Standard: http://www.iso.org/iso/iso8601
>>
>> ISO8601 is a standard for specifying Gregorian dates, times, datetime
>> intervals, durations, and recurring datetimes.
>>
>> An ISO8601 datetime is specified as: year, month, day, hour, ‘T’ or
>> space, minute, second, timezone.
>>
>> A Z timezone specifies Universal Coordinated (or “Zulu”) time.
>>
>>    - http://www.w3.org/TR/NOTE-datetime
>>
>> Examples of ISO8601:
>>
>> 2014
>> 2014-10
>> 2014-10-23
>> 20141023
>> 2014-10-23T20:59:30+Z       # UTC / Zulu
>> 2014-10-23T20:59:30Z        # UTC / Zulu
>> 2014-10-23T20:59:30-06:00   # CST
>> 2014-10-23T20:59:30-06      # CST
>> 2014-10-23T20:59:30-05:00   # CDT
>> 2014-10-23T20:59:30-05      # CDT
>> 20
>> 20:59
>> 2059
>> 20:59:30
>> 205930
>> 2014-10-23T20:59:30Z/2014-10-23T21:00:00Z
>> 2014-10-23T20:59:30-05:00/2014-10-23T21:00:00-06
>> PT1H
>> PT1M
>> P1M
>> P1Y1M1W1DT1H1M1S
>>
>> Note
>>
>> AFAIU, ISO8601 does not specify standards for milliseconds, microseconds,
>> nanoseconds, picoseconds, femtoseconds, or attoseconds.
>>
>
> On Thu, May 7, 2015 at 9:43 AM, Wes Turner <wes.turner@gmail.com> wrote:
>
>> Ralph,
>>
>> QUDT:
>>
>> From https://wrdrd.github.io/docs/consulting/knowledge-engineering#qudt
>>
>>> Homepage: http://www.linkedmodel.org/doc/qudt/1.1/
>>> Standard: http://qudt.org/
>>> Namespace: http://qudt.org/schema/qudt#
>>> xmlns: @prefix qudt: <http://qudt.org/schema/qudt#> .
>>> LOVLink: http://lov.okfn.org/dataset/lov/vocabs/qudt
>>>
>>> QUDT (*Quantities, Units, Dimensions, and Types*) is an *RDF*
>>> <https://wrdrd.com/docs/consulting/knowledge-engineering#rdf> standard
>>> vocabulary for representing physical units.
>>>
>>>    - QUDT is composed of a number of sub-vocabularies
>>>    - QUDT maintains conversion factors for Metric and Imperial Units
>>>
>>>
>> A few JSON-LD examples could be very helpful.
>>
>>
>> On Thu, May 7, 2015 at 7:21 AM, Ralph TQ [Gmail] <
>> rhodgson@topquadrant.com> wrote:
>>
>>> Hello Mark,
>>>
>>> QUDT is now a non-profit organization with the desire to join W3C to
>>> move forward on standardization. The management at NASA has given its
>>> approval for QUDT to proceed with this.
>>>
>>> Release 2 is a substantial body of work that is finally reaching a
>>> publication status. This involves the generation of content with support
>>> for LaTeX formatting. Examples can be seen at the following web pages:
>>>
>>>
>>>    1. The documentation on the QUDT schema -
>>>    http://www.linkedmodel.org/doc/2015/DOC_schema-qudt-v2.0
>>>    2. An example of a LaTeX rendered instance of the Hartree Unit -
>>>    http://www.linkedmodel.org/doc/2015/hartree
>>>
>>> The site www.linkedmodel.org has links to documentation for other
>>> ontologies and for those that QUDT depends on (VAEM, VOAG and DTYPE).
>>>
>>> All the QUDT ontologies are managed on a GitHub site. There is also a
>>> WordPress site.
>>>
>>> QUDT would welcome participation from others and once we become a member
>>> of W3C a working group would be important to establish. Perhaps we should
>>> have a discussion on how to get started?
>>>
>>> We have long believed that for (some) data to be truly linkable on the
>>> web it benefits from being quantified.
>>>
>>> I will send another email setting out the remaining work we are doing on
>>> the ontologies. In my view the most important of which is standardization
>>> of the QNames of the units (e.g, unit:SEC for second, unit:S for Siemen,
>>> and unit:KM-PER-SEC not unit:KM-PER-S) so that they are consistently
>>> reference-able and conforms with their standard abbreviations . This work
>>> is almost complete for SI units.
>>>
>>> Regards,
>>>
>>>
>>> Ralph Hodgson, @ralphtq <http://twitter.com/ralphtq>
>>>
>>> TopQuadrant, Inc., www.topquadrant.com @TopQuadrant
>>> <http://twitter.com/topquadrant>
>>> *cell: +1 781-789-1664 <%2B1%20781-789-1664> / fax: 703 299-8330
>>> <703%20299-8330> / main: 919 300-7945 <919%20300-7945>*
>>>
>>>
>>> On May 7, 2015, at 4:56 AM, Mark Harrison <mark.harrison@cantab.net>
>>> wrote:
>>>
>>> Dear Martin,
>>>
>>> I understand your very valid concerns about Linked Data resources that
>>> are not supported and maintained and end us wasting time for developers.
>>> However, from this thread it also seems that there is quite some interest
>>> in having a well recognised ontology for units of measure in which units
>>> have corresponding stable URIs that link to definitions, UN ECE codes,
>>> conversion factors and offsets, etc.  QUDT 1.1 made a very good start on
>>> this, although it had one or two inaccurate cross-references.  For example,
>>> I found within http://qudt.org/vocab/unit#Grain the following
>>> nonsensical triple:
>>>
>>> <http://qudt.org/vocab/unit#Grain>  skos:exactMatch  <
>>> http://dbpedia.org/resource/Cereal> .
>>>
>>> There are some other gaps in QUDT 1.1, such as missing resources for
>>> units such as milligram, microgram - and because the SI base unit of mass
>>> is the kilogram, it is not sufficient to simply define the multipliers such
>>> as 'milli', 'micro', because we don't usually talk about milligrams as
>>> microkilograms, for example.
>>>
>>> Having said that, if QUDT 1.1 were updated, corrected, supported a more
>>> complete set of units and provided cross-references to the corresponding UN
>>> ECE Common Code values as strings, I think it (or something very like it)
>>> could be an extremely valuable resource for everyone, especially because of
>>> the conversion factors and offsets.
>>>
>>> The QUDT.org website appears to be last updated in March 2014 and there
>>> is some information and a presentation by Ralph Hodgson (copied) about the
>>> plans for release 2.0 of QUDT.  However, I'm not sure whether that work has
>>> stalled or is under-resourced or is spending a long time in careful
>>> internal review.  Maybe those of us who are interested in making this
>>> happen could offer to share the workload and accelerate the progress.  In
>>> case NASA / TopQuadrant is no longer the place to host it, then perhaps we
>>> could reasonably ask W3C to host it in perpetuity and maintain a liaison
>>> with the UN, ISO and other relevant bodies to ensure that we're aware of
>>> their changes that should be reflected through maintenance updates to such
>>> a vocabulary.
>>>
>>> We're soon hoping to see much more structured data about products being
>>> published openly on the web as linked data, potentially including details
>>> about ingredients, nutrition and allergens.  GS1 has already prepared begun
>>> drafting a web vocabulary [ see
>>> http://www.gs1.org/gtin_plus_public_review ] to help manufacturers and
>>> retailers express such information in much richer detail than they can
>>> currently using schema.org alone - and efforts are underway to
>>> harmonise this effort with schema.org to make life easier for
>>> developers.  I expect that a stable supported ontology with URIs and Linked
>>> Data for units of measure along the lines of a QUDT 2.0 could be far more
>>> useful to software developers than simply denoting a unit of measure by its
>>> UN ECE Common Code string.  We can certainly do better than that.  It could
>>> almost certainly avoid a large amount of duplicated effort in coding
>>> conversion factors and offsets and would also help to ensure that whether
>>> the product specifications are provided in SI units or non-SI units (as
>>> they are in different regions of the world), the same quantitative
>>> information is readily available so software applications, without
>>> ambiguity or unnecessary duplication of effort by developers.
>>>
>>> I hope that Ralph Hodgson can chime in with a brief status update on
>>> QUDT 2.0 - and also that those of us who would be interested in helping to
>>> accelerate this (or something similar) can step forward and offer to help
>>> with reviewing it or beta testing it - or filling in the gaps for the
>>> missing features.
>>>
>>> Best wishes,
>>>
>>> - Mark Harrison
>>>
>>>
>>>
>>>
>>> On 7 May 2015, at 09:08, martin.hepp@ebusiness-unibw.org wrote:
>>>
>>> Dear Kingsley:
>>> Technically, as we agree, this is no big deal.
>>>
>>> But there are so many abandoned RDF / Semantic Web efforts rottening on
>>> the Web and wasting the time of developers who try to built something on
>>> top of it -- until they find out that the project is way out of date --
>>> that I do not see any gain in such a quick fix.
>>>
>>> Martin
>>>
>>>
>>> On 07 May 2015, at 01:25, Kingsley Idehen <kidehen@openlinksw.com>
>>> wrote:
>>>
>>> On 5/6/15 6:31 PM, martin.hepp@ebusiness-unibw.org wrote:
>>>
>>> The problem is not the one time generation. The problems are as follows:
>>>
>>> 1. Copyright - Are you allowed to republish the code set as RDF?
>>> 2. Sustainability - Are you commited to keep the URIs dereferencable, or
>>> will some domain grabber take the domain name once the creator has
>>> completed his/her PhD and lost interest.
>>> 3. Updates - Will you keep the RDF version in sync whenever the standard
>>> changes?
>>>
>>> Unless there is a clear "yes" to all three questions, it is better to
>>> use the official codes than derived URIs.
>>>
>>> Martin
>>>
>>>
>>> Martin,
>>>
>>> What's wrong with:
>>>
>>> <#someResolvableVariantOfIdentifier>
>>> a owl:Thing ;
>>> dcterms:identifier "{literal-variant-of-standard-identifier}" .
>>>
>>> Which can be further embellished by Linked Data publisher in their
>>> ontology/vocabulary by adding the following:
>>>
>>> dcterms:identifier
>>> a owl:InverseFunctionalProperty .
>>>
>>> Productive workflow:
>>>
>>> 1. Get the data dump in a spreadsheet
>>> 2. Save as CSV
>>> 3. Load into LOD or Google Refine
>>> 4. Map to relevant ontology (existing, or new)
>>> 5. Dump data into an RDF document
>>> 6. Publish (note: using # as indexical mechanism makes the publication
>>> Linked Open Data prinicples compliant off-the bat).
>>>
>>>
>>> It can be done quite easily. I deliberatly opted not to do it :)
>>>
>>>
>>> Kingsley
>>>
>>>
>>>
>>>
>>> On 06 May 2015, at 23:56, Wes Turner <wes.turner@gmail.com> wrote:
>>>
>>> How much time do you think it would take to generate RDF (and namespaced
>>> URIs) from the linked spreadsheet?
>>>
>>> Mappings to/from UN/CEFACT codes (as owl:sameAs mappings to strings)
>>> could certainly be useful.
>>>
>>> On May 6, 2015 4:31 PM, "martin.hepp@ebusiness-unibw.org" <
>>> martin.hepp@ebusiness-unibw.org> wrote:
>>> I think a validator should simply use the list of valid codes from the
>>> most recent UN/CEFACT document (available as MS Excel from
>>> http://www.unece.org/cefact/codesfortrade/codes_index.html).
>>>
>>> There might be unit of measurement ontologies out there that hold the
>>> UN/CEFACT Common Code string for a subset of all units as a literal value.
>>> But for validation, one should use the authoritative list from the Excel
>>> files (since they are updated from time to time).
>>>
>>> URIs are not better than strings for validation, because URIs are
>>> strings.
>>>
>>> Best wishes / Mit freundlichen Grüßen
>>>
>>> Martin Hepp
>>>
>>> -------------------------------------------------------
>>> martin hepp
>>> e-business & web science research group
>>> universitaet der bundeswehr muenchen
>>>
>>> e-mail:  martin.hepp@unibw.de
>>> phone:   +49-(0)89-6004-4217
>>> fax:     +49-(0)89-6004-4620
>>> www:     http://www.unibw.de/ebusiness/ (group)
>>>        http://www.heppnetz.de/ (personal)
>>> skype:   mfhepp
>>> twitter: mfhepp
>>>
>>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>>> =================================================================
>>> * Project Main Page: http://purl.org/goodrelations/
>>>
>>>
>>>
>>>
>>> On 06 May 2015, at 20:34, Wes Turner <wes.turner@gmail.com> wrote:
>>>
>>> Thanks!
>>>
>>> I notice that with QUDT there are SI conversion factors and complete
>>> URIs for each unit.
>>>
>>> Is there a schema for validation of "schema:QuantativeValues supports
>>> all UN/CEFACT Common Codes"?
>>>
>>> (A similar quandry as with MedicalCode; where URI namespaces (like
>>> icd10:) would be more helpful for terminological validation and
>>> disambiguation than plain string keys)
>>>
>>> On May 6, 2015 4:26 AM, "martin.hepp@ebusiness-unibw.org" <
>>> martin.hepp@ebusiness-unibw.org> wrote:
>>>
>>> Hi Wes,
>>> sorry for a very late reply:
>>>
>>> Actually you could easily use schema:QuantitativeValue for both time and
>>> volume, with SEC as the unit code for t and LTR as the unit code for
>>> liters, and link both via schema:valueReference, or better, and
>>> owl:subProperty thereof.
>>>
>>> For the principle, see
>>>
>>>
>>> http://wiki.goodrelations-vocabulary.org/Documentation/Structured_values_and_value_references
>>>
>>>
>>> schema:QuantativeValues supports all UN/CEFACT Common Codes for units,
>>> which should cover all you need:
>>>
>>>
>>>
>>> http://wiki.goodrelations-vocabulary.org/Documentation/UN/CEFACT_Common_Codes
>>>
>>> (Mind the full list in the public Excel files, the page just highlights
>>> a small subset.)
>>>
>>> Best wishes / Mit freundlichen Grüßen
>>>
>>> Martin Hepp
>>>
>>> -------------------------------------------------------
>>> martin hepp
>>> e-business & web science research group
>>> universitaet der bundeswehr muenchen
>>>
>>> e-mail:  martin.hepp@unibw.de
>>> phone:   +49-(0)89-6004-4217
>>> fax:     +49-(0)89-6004-4620
>>> www:     http://www.unibw.de/ebusiness/ (group)
>>>        http://www.heppnetz.de/ (personal)
>>> skype:   mfhepp
>>> twitter: mfhepp
>>>
>>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>>> =================================================================
>>> * Project Main Page: http://purl.org/goodrelations/
>>>
>>>
>>>
>>>
>>> On 01 May 2015, at 13:45, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
>>> wrote:
>>>
>>> Hi Wes,
>>>
>>> On 01/26/2014 07:20 AM, Wes Turner wrote:
>>>
>>> Say I am trying to share a tabular dataset. [1] There's metadata for
>>> the Dataset, and there's metadata for the particular columns (which
>>> applies to the particular data items).
>>>
>>> For example:
>>>
>>> t   volume (liters)
>>> -----------------
>>> 1  1
>>> 2  0.7
>>> 3  0.5
>>> 4  0.3
>>> 5  0.1
>>>
>>> Questions
>>> ===========
>>> # Is there (a good) way to specify these units and quantities (in
>>> addition to XSD datatypes)?
>>>
>>> You might like to check out
>>> * https://iotdb.org/pub/iot-unit.html
>>>
>>> Cheers!
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Kingsley Idehen
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com
>>> Personal Weblog 1: http://kidehen.blogspot.com
>>> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
>>> Twitter Profile: https://twitter.com/kidehen
>>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Wes Turner
>> https://westurner.org
>> https://wrdrd.com/docs/consulting/knowledge-engineering
>>
>
>
>
> --
> Wes Turner
> https://westurner.org
> https://wrdrd.com/docs/consulting/knowledge-engineering
>



-- 
Wes Turner
https://westurner.org
https://wrdrd.com/docs/consulting/knowledge-engineering