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

Hi Alex,
> some kind of concept that works for both.  For example, weather reports can be thought of as news content and they can also be more regular data sets produced by various weather-related agency's monitoring efforts (e.g. NOAA organizations).
> 
> 
> Quick feedback inline below:
> 
> >
> >   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).
> ...
> I still fail to see why ISO 8601 semantics and syntax (akin to XML Schema's datatypes) shouldn't be directly allowed.
>  
Because it is much more difficult to execute queries that check whether a certain quantitative criterion is met when the data can be both a point value or an interval. For doing this with the current mechanism, you do not need more than to expand a point value to an interval with min=max, and this will work with any XSD datatype. Doing this with ISO 8601 requires a specific mechanism just for date and time datatypes.
The current approach is a single solution for a wide range of datatypes. 

> 
> >
> >   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.
> ...
> Note that you can use the properties of depth, heigh, width, and weight for any object of choice in the current form.
> ...
> Not if they expect unit codes that make no sense in other contexts.

I fail to see why, since UN/CEFACT has reliable codes for all SI units.


> > 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.
> 
> Prefix?  I'm not sure I understand what you mean: prefixed as in CURIE or prefixed with some string (e.g. "si.") ?
>  
I meant a string prefix for a textual value, like uncefact:HUR or si:kg

> >
> > 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.
> 
> ...
> 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).
> 
> I am well familiar with UN/CEFACT but I think their codes are a non-starter for any kind of scientific or sensor data.  Why would you adopt a unit symbol that isn't the actual accepted symbol used within the greater scientific community?

We are talking about marking up data on the Web in here, thus the codes used are intended mostly for machines, not humans. I think that having short, unique three-letter codes from a small alphabet is a much more reliable mechanism than using the original SI symbols, that require proper Unicode encoding etc.

 
> 
> > [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
> 
> Certainly good to know.  
> 
> In my opinion, I don't like the idea of a prefix.  The "unitCode" needs to be a URI so it can play well on the Web. 
> 

From a "linked data" perspective, URIs may make sense. From a markup perspective, they are long and ugly and as long as you do not have an authoritative URI that is dereferenceable, then a URI is as good or bad as any unique string. In short, URIs for enumerations are overrated in the context of schema.org.


> 
> >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.
> 
> Often true but the current properties feel too skewed towards UN/CEFACT-based commerce.  It is possible that these two domains may not mix well.
> 

I think you are misunderstanding me. While schema:QuantitativeValue is a very generic element, the height/depth/width properties are (currently) meant and defined for http://schema.org/Product only. 

I fail to see why http://schema.org/QuantitativeValue should be limited or biased towards commerce.

Martin

--------------------------------------------------------
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 Wednesday, 21 August 2013 21:34:36 UTC