W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: incomplete datatyping (was: Re: datatypes and MT)

From: <Patrick.Stickler@nokia.com>
Date: Wed, 7 Nov 2001 13:12:08 +0200
Message-ID: <2BF0AD29BC31FE46B78877321144043114C074@trebe003.NOE.Nokia.com>
To: Graham.Klyne@MIMEsweeper.com, phayes@ai.uwf.edu
Cc: melnik@db.stanford.edu, w3c-rdfcore-wg@w3.org

> -----Original Message-----
> From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
> Sent: 07 November, 2001 12:15
> To: Pat Hayes
> Cc: Sergey Melnik; w3c-rdfcore-wg@w3.org
> Subject: Re: incomplete datatyping (was: Re: datatypes and MT)
> There's a wrinkle here that occurs to me...
> At 10:32 PM 11/6/01 -0600, Pat Hayes wrote:
> >>_y firstName "Sergey"
> >>_y lastName "Melnik"
> >>_y monthOfBirth "July"
> >>_y dayOfBirth "Tuesday"
> >>
> >>I'd see that as only meaningful if you also said how to 
> interpret the 
> >>literals. So for example I presume it might be kosher to assume
> >firstName rdfs:range xsd:string .
> >lastName rdfs:range xsd:string .
> >but that we might also need something like
> >monthOfBirth rdfs:range xxd:EnglishCalendarMonth
> [...]
> >>You are saying that as long as there is no schema it's a 
> literal value.
> >>Once a schema is there, it becomes a data value. To satisfy
> >>monotonicity, all data values must then necessarily be 
> literal values,
> >>right?
> >
> >I don't know what a data value is. By literal value I meant 
> the semantic 
> >value of the literal, ie the value of the XL mapping applied to the 
> >literal. So a literal always denotes the same thing in a 
> given datatype 
> >interpretation, but when no schema information is present, there are 
> >several alternative such interpretations which satisfy the 
> graph, and it 
> >might denote something different in each one.
> >
> >Nothing *changes* when schema information is added, exactly, 
> but the set 
> >of satisfying datatype interpretations is reduced, in the 
> usual way, and 
> >that may be enough to fix the interpretation of the literal 
> in all the 
> >interpretations that satisfy the graph.
> Suppose that in addition to:
>    monthOfBirth rdfs:range xxd:EnglishCalendarMonth .
> we can also presume:
>    monthOfBirth rdfs:range xxd:decimalInteger .
> (this being legit RDF) ... might the allow us to write:

But a property may only have one range. Right? So this isn't
legit RDF. Or has that changed?

One could, however, define a data type that is the union
of xxd:EnglishCalendarMonth and xxd:decimalInteger (or
perhaps more precisely xxd:integerMonth) and then
define that as the range, so the example is still valid.
   monthOfBirth rdfs:range xxd:month .
   xxd:EnglishCalendarMonth rdfs:subClassOf xxd:month .
   xxd:integerMonth rdfs:subClassOf xxd:month .
   xxd:integerMonth rdfs:subClassOf xxd:decimalInteger .


>    _y monthOfBirth "July" .
> OR
>    _y monthOfBirth "7" .
> ?

Now, presumably, the lexical space for xxd:month takes
into account the lexical spaces for xxd:EnglishCalendarMonth
and xxd:integerMonth, and must be able to differentiate
these lexical spaces when interpreting the value. However,
if provide for local typing, this greatly simplifies the
interpretation, as each sub-lexical space of xxd:month
remains distinct. Thus:

    _y monthOfBirth <xxd:EnglishCalendarMonth:July> .
    _y monthOfBirth <xxd:integerMonth:y> .

Now, both values satisfy the range constraint for xxd:month
as both value types are subclasses of xxd:month, but the
lexical space of each lexical form is also explicitly defined.
> There are two points I see here:  (a) multiple datatype classes might 
> permit ambiguity in the value denoted by a given literal 
> string, and (b) a 
> literal value might not have a defined mapping under some 
> presumed datatype 
> class.
> (a) I see as not really being different from the case where 
> no datatype 
> class information is available, except that it seems to run 
> counter to the 
> conjunctive nature of type information.
> (b) if no mapping is provided by a presumed datatype class, 
> how does this 
> affect the truth of the corresponding statement?
> #g

This serves to underline my assertion that local data types
are really manditory if you wish to reliably interpret literals,
and that range definitions don't provide enough information
to reliably interpret literals, only to test whether they
conform to such constraints, and that only can happen when
types are defined locally.

Thus, again, rdfs:range is only prescriptive, not descriptive,
which really, as I understand it, should bear out from the
fact that the RDFS spec defines it as a constraint, and even
though there may be the suggestion that it might serve as a descriptive 
mechanism for "reasoning applications" for inferring the data type
of non-locally typed literals, that doesn't seem to fit with
its explicitly stated purpose as a constraint (i.e. a prescriptive
mechanism) and I think its apparent that this suggestion was
not intended to be a normative specification of its use as such.


Received on Wednesday, 7 November 2001 06:14:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC