search

linked-usdl / usdl-core

Linked USDL core is a the foundation module for the Linked USDL family of vocabularies. It basically covers four essential aspects: i)service descriptions, ii) service offerings descriptions, iii) business entities involvement, and iv) service delivery communication channels and interaction points.
5 stars 1 forks source link

gr:hasUnitOfMeasurement #12

Closed jorge-cardoso closed 11 years ago

jorge-cardoso commented 12 years ago

Is there any way to use a set of standard units of measurements? Of course, it is impossible to define all the possible units, but maybe for the most common, e.g. days of the week, months, years, etc.

drleidig commented 12 years ago

GoodRelations uses UN/CEFACT Trade Facilitation Recommendation No. 20 common codes for the units of measurement. So we have do do the same. These are just 3 letter alphanumeric codes.

E.g.

Year is "ANN", month is "MON", week is "WEE", day is "DAY", kilosecond is "B52" ;-)

Certainly not all units are in this list (it's more for e-commerce), although there are more then thousand codes).

jorge-cardoso commented 12 years ago

The usdl example I have seen from Amazon EC2 defined its own units of measurement. I even think I seen a few codes from SAP internal coding system. The example should to be corrected in the future.

drleidig commented 12 years ago

If the examples use its own unit of measurement than this is a fault. The examples should be corrected. Can you give me a pointer?

cpedrinaci commented 12 years ago

There are a couple of options that come to my mind: QUDT - http://www.qudt.org/ Freebase's units (http://www.freebase.com/view/measurement_unit/views/measurement_system)

There's a lot we could build upon.

Interestingly though GR doesn't use any of this. I would suggest using proper units based on one of the options above.

jorge-cardoso commented 12 years ago

For example,

:resource_EC2_PrivateIP a cloud:IPAddress ; gr:valueReference [ a cloud:PrivateIPAddress ] , [ a cloud:StaticIPAddress ] , [ a genVoc:Quantity ; gr:hasUnitOfMeasurement "C62" ; gr:hasValue "1" ] .

"The unit of measurement is specified using the property gr:hasUnitOfMeasurement with a string holding a UN/CEFACT code suitable for durations, e.g. MON (months), DAY (days), HUR (hours), or MIN (minutes)."

So I assume that "C62" is a UN/CEFACT code. If this is the case, then no errors in the Amazon service modeling.

drleidig commented 12 years ago

According to Carlos proposal, I think we have to keep in mind

*compatibility with GoodRelations

In gr we have:

foo:mass a owl:ObjectProperty;
    rdfs:domain gr:ProductOrService;
    rdfs:range gr:QuantitativeValue;
    rdfs:subPropertyOf gr:quantitativeProductOrServiceProperty .

 <#xyz> foo:mass
    [ a gr:QuantitativeValueFloat;
      gr:hasValue "12";
      gr:hasUnitOfMeasurement "KGM";
   # alternatively you can define a range:
      gr:hasMinValue "5";
      gr:hasMaxValue "12" ].

with qudt it would look like;

foo:mass a owl:ObjectProperty;
    rdfs:domain usdl:Service;
    rdfs:range qudt:QuantityValue;
    rdfs:subPropertyOf usdl:quantitativerServiceProperty . # to be defined

<#xyz> foo:mass
     [  a qudt:QuantityValue;
        qudt:numericValue "12"^^xsd:double;
        qudt:unit <http://data.nasa.gov/qudt/owl/unit#Kilogram> ].

# what about min-max ranges?
drleidig commented 12 years ago

What do you think about the following:

We could go a similar way as with the dc:subject for legacy reasons, which could either be a string or a resource URL.

We just go with GoodRelations but recommend the use of an URL to denote the Unit foo:mass a owl:ObjectProperty; rdfs:domain gr:ProductOrService; rdfs:range gr:QuantitativeValue; rdfs:subPropertyOf gr:quantitativeProductOrServiceProperty .

 <#xyz> foo:mass
    [ a gr:QuantitativeValueFloat;
      gr:hasValue "12";
      gr:hasUnitOfMeasurement <http://data.nasa.gov/qudt/owl/unit#Kilogram>;
    ].
jorge-cardoso commented 12 years ago

If no URL is given then it will by default use gr:?

cpedrinaci commented 12 years ago

I would not opt for this approach since it is neither one nor the other. Software dealing with QUDT would do so bearing in mind its entirety not just looking up for units.

In this case, if we want to stick to just unit look up, I would favour Freebase's units as no further theory is embedded on it (I think).

Still, for future proper handling of units I think that and entire embedding of QUDT with the capability for importing those defined a la GR is more appropriate. Otherwise this will lead to a high number of hacks in software and issues in the future.

drleidig commented 12 years ago

What do you mean by "entire embedding of qudt"? Can you give an example?

I expect, that a person describing a service property will just enter the value (or range) and the unit. The latter will already be defined for a specific domain.

drleidig commented 11 years ago

proposed solution is using freebase:

Action: Talk to Martin Hepp about taking over this approach.