RE: Literals (Re: model theory for RDF/S)

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 03 October, 2001 20:25
> To: Stickler Patrick (NRC/Tampere); pfps@research.bell-labs.com;
> tpassin@home.com
> Cc: www-rdf-logic@w3.org
> Subject: Re: Literals (Re: model theory for RDF/S)
> 
> 
> > I don't see anything wrong with how DAML encorporates
> > XML Schema data types. It may be, though, that such data
> > type mechanisms should live at a lower level, namely RDFS
> > -- or maybe not. I'm undecided about that.
> >
> > They don't, though, belong IMO at the RDF level, in the
> > graph.
> 
> Wow, I agree with you! 

And a tremor shook the earth...   ;-)

> There was some discussion that when a datatyped
> literal is added to an internal RDF store, it should be given 
> an ID so that
> the application can keep track of its type-ness. In other 
> words, when you
> have:-
> 
>    "xyz" a :X .
>    "xyz" a :Y .
> 
> you should add IDs to the literals internally to keep a track 
> of them... so
> that they are noted as being different. But that's rubbish, 
> because they're
> noted as being different in the model, and the model is 
> preserved in the
> application. If the model loses the information about the 
> typing, it does
> not need to retain the ID information, because it no longer 
> believes the
> strings to be typed as anything more specific that simply 
> rdfs:Literal.
> 
> Bigger problems that face designers of internal RDF stores 
> include how to
> do asserted reified statements, and fiddling about with contexts.

Well, if "scoping" (a'la XTM, ISO Topic Maps) were added as
a primitive feature of the graph, rather than having to resort
to typed anonymous nodes, then one could see data typing of
literal values as just a scope, like any other qualification.

Still, wherever one defines the data type of a literal, it
results in the same amount of information: a data type
identifier, and a literal value.

A URI scheme approach seems to me to be the most condensed
form, and offers the ability to use RDF to define additional
knowledge both about the scheme and particular instances
of that scheme (and may be the first valid use of the
possibly prematurely deprecated aboutEachPrefix construct ;-)

Note that it's not possible to define data type at the
property level (i.e. what data types the property can take)
as both one cannot differentiate between ranges of different
types of literals, and even if one could, one could not
then differentiate between different literals which are
string equivalent but belong to different types, both of
which are acceptable ranges for the property.

One must define data type for every occurrence of a literal.

A data literal URI is IMO a very efficient and effective
way to do that.

And if we can do that, then we can simply call literals
resources (which they appear to be in the MT) and simplify
a whole lot of core machinery.

> But, I still disagree with generating a new URI scheme for 
> datatypes. There
> is no real difference between:-
> 
>    "xyz" rdf:type :abc .
> 
> and:-
> 
>    <lit:abc:xyz> a rdfs:Resource .
> 
> Except that the former is decentralized and keeps more inline with the
> whole principle of the Semantic Web, which is 
> decentralization. It wouldn't
> be so bad to have a range of very, very, important literals 
> in a "lit:" URI
> space (they could then be used by non-RDF systems), but you 
> certainly can't
> have a centralized URI scheme for every datatype ever; it's 
> pointless (and
> most likely, you're not suggesting that).

No I'm not. Though, it is possible to define minimally decentralized 
URI schemes for typed data literals -- though to be honest, I think 
I'd prefer having a centralized authority such as IETF, W3C, IEEE, 
ISO, etc. defining most of my data types, eh?

Regards,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Nokia Research Center                 Fax:    +358 7180 35409
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Thursday, 4 October 2001 04:01:55 UTC