RE: Units (inches and centimetres, etc)

I think the underlying problem is hard to do well, and there is a danger
that one looks at it and thinks its easy and does a bodge job.

In particular I urge that enough levels of indirection are included.
'enough' probably means one more than you think is necessary, even taking
this rule into account!

e.g.

Maybe a resource of type distance has a measure with unit centimetre and
with value 30.

_:r rdf:type eg:Distance .
_:r eg:measure _:b .
_:b eg:unit eg:centimetre .
_:b eg:value "30"^^xsd:decimal .

eg:value rdf:type owl:FucntionalProperty .
eg:unit rdf:type owl:FunctionalProperty .


We might then want
eg:lengthInCentimetres rdfs:subPropertyOf eg:measure .

eg:lengthInCentimetres rdfs:range _:rg .
_:rg rdf:type owl:Restriction .
_:rg owl:onProperty eg:unit .
_:rg owl:hasValue eg:centimetre .

eg:lengthInCentimetres rdf:type owl:FunctionalProperty .

So, to say that I am 175 cm tall we might have

<#Jeremy> eg:height _:d .
_:d rdf:type eg:Distance .
_:d eg:lengthInCentimetres _:x .
_:x eg:value "185"^^xsd:decimal .

with two blank nodes separating the thing being measured from the number.

This allows stating that eg:height is fucntional, while allowing both the
expression of height in centimetres or metres.

There is a functional path from <#Jeremy> to "185"

Jeremy



> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Graham Klyne
> Sent: 16 June 2003 19:21
> To: danny666@virgilio.it; RDF interest group
> Subject: RE: Units (inches and centimetres, etc)
>
>
>
> I think we're in considerable agreement -- I maybe wasn't clear enough.
>
> My suggestion was that just that the arithmetic *vocabulary* as
> implemented
> by CWM be written up so that it's easier for a community of use to build
> up.  Any problems would then get identified and could be folded into a
> subsequent standardization process.
>
> I suggested the CWM vocabulary because it exists, and see no point in
> inventing another one.  If there's another candidate, then by all means
> consider that.  Or if there's a real problem with CWM's vocabulary, let's
> know about it.  I think a fair number of people will copy CWM's
> vocabulary
> anyway, as has happened with predicates like log:implies and friends.
>
> (In general, I wouldn't especially advocate standardizing
> vocabularies, but
> arithmetic seems to be sufficiently fundamental... it's difficult to do
> anything seriously without getting some level of arithmetic involvement.)
>
> As for the service aspect, I think that smacks too much of computation,
> where RDF is about expressing truths.
>
> Ultimately, as far as RDF is concerned, property/ies indicates
> relationship/s between values.  Whether those relationships are
> defined/presented in terms of the result of a well-known service
> (multiplication), or in terms of a mathematical description of the
> properties of such a service (e.g. 0*x=0, 1*x=x, x*y=y*x,
> succ(x)*y=x*y+y,
> etc) doesn't matter for that purpose, as long as the semantic
> interpretation applied yields the expected truths and non-truths.  When
> these relationships are used in an inference process, then you may need
> some "service" to actually perform evaluations.
>
> The property URIs simply identify the relations;  in performing
> inference,
> it's the inference engine's responsibility to apply processes (services)
> that are consistent with those relations.
>
> #g
> --
>
> At 18:18 16/06/03 +0200, Danny Ayers wrote:
> > > This suggests to me that we don't really need anything new that isn't
> > > already being done.  There's a lot of activity devoted to the
> development
> > > of rules [2] [3].  It seems that there already exists a design for RDF
> > > properties dealing with relations based on arithmetic operations [1],
> > > though I could see a case for making that work a little more
> > > "forceful" --
> > > e.g. by publication as a W3C Note, with a view to taking it to the
> > > recommendation track in future RDF working groups.
> >
> >I think cwm is wonderful, but I'm not sure how far it should be
> considered a
> >role model. Being able to plugin a procedure at the drop of the hat is
> >sweet, but unless that procedure is made explicit then
> everything could get
> >very shaky. Being able to call on a reproducible
> algorithm/process/service
> >to carry out a conversion is one thing, having it be a black box
> is another.
> >Personally I'd favour drawing a line in the sand around simple
> comparisons
> >(==, > etc) applied to typed literals which could form a little
> package of
> >quasi-builtins for use with rules. Where any f beyond this is
> needed then I
> >think this would be best viewed as a service, even if it is carried out
> >locally as Chaals suggested.
>
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
>
>

Received on Tuesday, 17 June 2003 05:53:45 UTC