Re: [SUMMARY] QuantitativeValue / Units of Measure - Proposal

Dear Alex:

Thanks for the contribution. As far as I am concerned, it is in a big pile of things to address. I would say that most people in this community have many things on their agendas, so they will often not be able to act immediately upon generally relevant input. So one has to be patient when expecting to see action on good proposals. Also note that the priorities of many people involved in here will be based on how much new data or new data sources (e.g. sites) can be expected on the basis of a new proposal. Conceptually well-justified proposals that will likely have no immediate impact on how site owners actually expose Web content are less urgent.

Quick feedback inline below:

On Aug 16, 2013, at 10:49 PM, Alex Milowski wrote:

> Hmm ... not a single reply of feedback on this since June.
> 
> Does that mean:
> 
> A. people aren't interested,
> B. not interested at this time,
> C. wait, what?
> D. you're off your rocker.
> 
> ?
> 
> 
> 
> On Thu, Jun 6, 2013 at 2:21 PM, Alex Milowski <alex@milowski.com> wrote:
> I went through the schemas and found the uses of http://schema.org/QuantitativeValue:
> 
> Time Duration:
> 
> http://schema.org/advanceBookingRequirement
> http://schema.org/deliveryLeadTime
> http://schema.org/durationOfWarranty
> http://schema.org/eligibleDuration
> 
> Dimensions / weight
> 
> http://schema.org/depth
> http://schema.org/height
> http://schema.org/weight
> http://schema.org/width
> 
> Counts (possibly unit less?)
> 
> http://schema.org/eligibleQuantity
> http://schema.org/inventoryLevel
> 
> Having some familiarity with the UN/CEFACT efforts, I also went through their unit codes and I find them troubling for general use:
> 
>   1. XML Schema's durations aren't possible.  A great deal of effort went into making a value space and lexical representation that is based on ISO time standards (ISO 8601).

In the GoodRelations part, this is handled via a unique mechanism for a common representation for point values and intervals.

A QuantitativeValue has a minValue, maxValue, and value property. The value property is a subproperty of minValue and maxValue.

So if you set a point value, it is internally also an interval with minValue=maxValue.

This is useful for queries, because if you search for a certain value, you will also find matches for intervals that include the point value. For instance, the search for a device that operates on 12 volts will also find one that is said to operate on 9 - 24 volts.

A time duration is simply an interval with minValue and maxValue plus a suitable unit code (like HUR for hours).

> 
>   2. The codes are odd for common use (e.g. Hour = HUR, instead of 'H' or 'h', ANN = year, instead of 'yr' or 'Y', GRM = gram, instead of 'g')
> 
They are a bit cryptic, but non the other hand unique and reliable. For instance, there are many variants of miles, and UN/CEFACT has individual codes for all of them.

>   3. There are very general properties of depth, heigh, width, and weight for which I could expect to use outside of UN/CEFACT contexts.

Historically, properties for product characteristics were defined only outside of GoodRelations in complementing domain extensions, like

    http://wiki.goodrelations-vocabulary.org/Vocabularies

But in the context of the first wave of adoption of GoodRelations by Google, we decided to integrate a few, very common properties to the core.

Note that you can use the properties of depth, heigh, width, and weight for any object of choice in the current form.

> 
> That said, I do think it makes sense to have a "unit code" property for contexts where UN/CEFACT information is being described.  That property should never be used for other purposes because of the broad nature of these codes and the fact that a random two or three letter code could mean something (e.g. 11 = outfit).

We may consider to add a more generic "unit" property for units given in plain text, but that is on hold due to a more generic proposal for weakly structured product properties. I will keep this list posted.

As of now, you could use a prefix with unitCode for SI codes.
> 
> On the other hand, if I want to describe the weight of an object using SI units, I need a way to say that with a different property.  That is, I should be able to use the standard prefixing scheme of SI units to say "kg", "g" "mg" and so on without having to resort to looking up a strange code.

The choice for UN/CEFACT codes is motivated in 

http://www.heppnetz.de/projects/goodrelations/GoodRelations-TR-final.pdf

in particular in sections 

3.1.6 Product or Service Properties
3.2.1 Units of Measurement

UN/CEFACT provides reliable codes for most if not all SI units plus many more, commonly needed ones for commerce.

Also, many back-end systems readily support UN/CEFACT codes (e.g. PDM systems).

> 
> If you look at Wikipedia's entry on SI units [1] or  QUDT [2], you'll see the consistent terminology for a unit abbreviation is "symbol".  Since we have one namespace, "symbol" alone has far too many interpretations and so "unitSymbol" might be better.
> 
> As mentioned before, grounding a unit by some well defined concept is a really good idea and URI is seems the best option because it will integrate well with QUDT.
> 
> Proposal:
> 
> Add two properties to QuantitativeValue: one for the unit symbol and one for the unit's "reference URI":
> 
>     http://schema.org/unitSymbol - the unit symbol, a string value
>     http://schema.org/unit - the URI of the unit's definition (e.g. QUDT unit:Gram, expanded)
> 
> and this allows:
> 
>     <p typeof="QuantitativeValue">
>         <span property="value">10</span><span property="unitSymbol">g</span>
>     </p>
> 
> and alternatively, for more specificity:
> 
>     <p property="weight" typeof="QuantitativeValue">
>         <span property="value">10</span><span property="unitSymbol">g</span><span property="unit" resource="unit:Gram"/>
>     </p>
> 
> or
> 
>    <p property="weight" typeof="QuantitativeValue">
>        <span property="value">10</span><span property="unitSymbol"><span property="unit" resource="unit:Gram">g</span></span>
>    </p>
> 
> [1] http://en.wikipedia.org/wiki/International_System_of_Units
> [2] http://www.qudt.org/

As said, I am in general fine with

- adding a unit property for pure textual unit references
- adding a prefix mechanism that allows additional unit codes to be used with unitCode

However, if you expand the range of options in the markup, you make the consumption for clients more difficult, so less applications will be able top fully understand the data.

Second, the integration with QUDT works perfectly as of now, as Dean Allemang has shown in the 2011 edition of his book "Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL".


Martin

> -- 
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
> 
> Bertrand Russell in a footnote of Principles of Mathematics
> 
> 
> 
> -- 
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
> 
> Bertrand Russell in a footnote of Principles of Mathematics

--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp@ebusiness-unibw.org
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/

Received on Tuesday, 20 August 2013 07:54:18 UTC