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

On Tue, Aug 20, 2013 at 12:53 AM, Martin Hepp <
martin.hepp@ebusiness-unibw.org> wrote:

> 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.
>

Certainly.  I understand this perspective but if any kind of scientific
data is going to have overlap with schema.org, then units need to be
grounded on 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).
>
> 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).
>

I still fail to see why ISO 8601 semantics and syntax (akin to XML Schema's
datatypes) shouldn't be directly allowed.


>
> >
> >   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.
>

Not if they expect unit codes that make no sense in other contexts.

> 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.") ?


> >
> > 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).
>

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?


>
> > [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.


> 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.


> 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".
>

I will certainly take a look at that.  Thanks.

-- 
--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