Re: literals must be self-evident

>Hi Pat,
>
>Literals formed the main technical discussion at the telecon last Friday.

I wish I'd been there.

>  My understaning, (haven't checked the minutes yet) is that we 
>agreed that there is an important choice to be made between on the 
>one hand your choice 2, where the type is 'part of' the literal, and 
>other choices where the type information is represented in the 
>structure of triples.

Right, that is a basic choice, I agree. However I now think that we 
can provide a single mechanism that accommodates both cases (as far 
as the MT is concerned anyway.) So if a literal has its typing 
built-in, then fine; but if not, then it can be determined from 
context. You can have it both ways.

>I'll probably get this wrong from logical point of view, but I've 
>got another terminological problem.  I wonder if it would help to 
>talk about representing instances of concrete data types, such as 
>int, date, float etc, thus distinguishing between what RDF currently 
>calls literals and these other beasties.

I guess Ive been assuming that a general-purpose literal datatyping 
mechanism ought to be able to handle things like this, up to a point 
at any rate. I presume that if someone were to invent a new 
datatyping scheme for some purposes, say mathxsd:float or some such, 
then in an ideal world it should be possible to adapt RDF smoothly to 
use that without going back to the drawing board. So even if they are 
not RDF literals right now, we ought to fix things so that they could 
be considered literals without completely re-doing everything, 
provided that we can do it relatively easily.

Pat


>Brian
>
>Pat Hayes wrote:
>
>>>At 12:43 PM 10/17/01 -0500, Dan Connolly wrote:
>>>
>>>>That is: it's essential that the interpretation of
>>>>an RDF document is a function of the document alone,
>>>>and doesn't vary according to the contents of other
>>>>documents.
>>>
>>>
>>>I think I agree with the thrust here, but I'd like to clarify 
>>>something:  it may be that access to another document will provide 
>>>more detailed information about what is stated in a document (e.g. 
>>>knowing the domain/range of a property from a separate schema may 
>>>allow one to make additional inferences about resources used in an 
>>>otherwise stand-alone document).
>>>
>>>The key requirement here seems to be that the interpretation of a 
>>>document in isolation cannot be invalidated when some external 
>>>document is also consulted.  (This seems to be a kind of 
>>>monotonicity.)
>>>
>>>Thus, I think what you are asking is that the truth under any 
>>>given interpretation of some RDF document is invariant; 
>>>consulting another document may restrict the interpretations that 
>>>are considered to be models.
>>
>>
>>Right, exactly. Thats how the extended MT would work. A datatyped 
>>intepretation is an interpretation (of the vocabulary) and a 
>>datatyping scheme (of the nodes) which together satisfy some pretty 
>>obvious semantic constraints (that the class extension of a 
>>datatype name is that datatype, and that every literal occurrence 
>>labels a node which is datatyped consistently with the class 
>>membership of the literal value.) Then it all works smoothly in the 
>>usual way, where the more you know, the smaller the set of typed 
>>interpretations gets. Since the typing is applied to nodes, it's 
>>impossible for typing in one graph to directly influence that in 
>>another (ie except via their mutual constraints on the shared 
>>vocabulary used on those node labels.)
>>
>>Pat
>>
>>>#g
>>>
>>>
>>>------------------------------------------------------------
>>>Graham Klyne                    MIMEsweeper Group
>>>Strategic Research              <http://www.mimesweeper.com>
>>><Graham.Klyne@MIMEsweeper.com>
>>>------------------------------------------------------------


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 23 October 2001 21:48:24 UTC