Re: (Round 2) Proposed Extensions to OWL

I see Jon's point, but am not totally convinced that another resource
is necessary. (1) More attributes can be supplied for the "length" 
property.  (2) I think the logic of a "measurement" resource could be 
applied equally well to a "length" property.

Dick McCullough
knowledge := man do identify od existent done;
knowledge haspart proposition list;

----- Original Message ----- 
From: "Roger L. Costello" <costello@mitre.org>
To: <www-rdf-interest@w3.org>
Cc: "Costello,Roger L." <costello@mitre.org>; <jon@spin.ie>
Sent: Monday, July 07, 2003 3:55 AM
Subject: Re: (Round 2) Proposed Extensions to OWL


> 
> "Richard H. McCullough" wrote:
> > 
> > This conceptual model is OK, but unnecessarily complicated,
> > and produces RDF descriptions which are just too long.
> > 
> > Since these physical quantities are just literal numbers,
> > they can be expressed as attributes of attributes, e.g.
> >     <ex:River ex:Yangtze>
> >         <ex:length units:kilometer=6300/>
> >     </ex:River>
> 
> Hi Richard,
> 
> Jon Hanna addressed this very nicely last Thursday.  He wrote:
> 
> This has advantages of brevity. However we can't deal as well with:
> 
> <River rdf:ID="Yangtze">
>     <length>
>         <Length len:lengthInMiles="3914"/>
>     </length>
>     <length>
>         <Length len:lengthInMiles="3900"/>
>     </length>
> </River>
> 
> (Which might occur if we had two sources for lengthInMiles with
> different degrees of precision).
> 
> We could deal with:
> 
> <River rdf:ID="Yangtze">
>   <length>
>     <Length>
>       <measurement>
>         <LengthInMiles number="3914">
>       </measurement>
>       <measurement>
>         <LengthInMiles number="3900">
>       </measurement>
>     </Length>
>   </length>
> </River>
> 
> Because the two measurements are (at least possibly) distinct despite
> their being only one length with only one Length. This also gives us
> somewhere to put information about the degree of precision, whether the
> application producing the value is authorised and/or tested by some
> organisation (say NIST, NWML, LMS etc.) and so on.
> 
> The greater notational and processing burden is appropriate for
> something that intends to cope with a large range of needs for
> measurements and conversions. A more abbreviated version like
> len:lengthInMiles would be more appropriate much of the time, allowing
> support for both styles would be ideal.
> 
>

Received on Monday, 7 July 2003 07:27:23 UTC