Re: datatypes and MT

Patrick.Stickler@nokia.com wrote:
> 
> >       <rdf:Description rdf:about="#me">
> >         <shoeSize>
> >            <integer decimalRep="10"/>
> >         </shoeSize>
> >     </rdf:Description>
> 
> The problem with this representation is that if we add
> additional qualification to the literal value, e.g.
> 
>     <integer decimalRep="10" foo:bar="xyz"/>
> 
> then an application that does not understand the specific
> semantics of any vocabulary other than RDF and RDFS (such
> as a generic tool) does not know which is the actual
> value of the property 'shoeSize'... "10" or "xyz" since
> insofar as the graph representation is concerned, they
> are equally opaque.
> 
> IMO, regardless of the final mechanisms employed and the
> level of typing or qualification of literals, it should
> *always* be possible for a generic application to
> differentiate on the basis of the graph itself, which
> "child" of a property node constitutes the value node
> and which are simply qualifications of that value.
> 
> The above proposal does not, as far as I can see,
> provide for that reliable distinction.

As far as I can see it, the reliable distinction you are talking about
is not always possible. Think of the following case:

<complex realDecimal="1.0" imaginaryDecimal="2.0"/>

as in

_x rdf:type complex
_x realDecimal "1.0"
_x imaginaryDecimal "2.0"

Above, properties realDecimal and imaginaryDecimal can be thought of as
"partial mappings" from the lexical space of decimals to the value space
of complex numbers. Each of the properties restricts the interpretation
of the complex value. However, the complex value can be pinned down
unambiguously only using *both* property values. In other words, the
interpretation of _x is functionally determined by the two property
values.

(As a side remark: of course, I'd prefer a different type of modeling,
in which the complex number is composed of two real numbers rather than
gets determined by two lexical tokens.)

Sergey

Received on Monday, 5 November 2001 17:05:56 UTC