- From: Garret Wilson <garret@globalmentor.com>
- Date: Thu, 26 Jul 2007 17:05:39 -0700
- To: Semantic Web <semantic-web@w3.org>
Garret Wilson wrote: > vcard.bday:@1980-01-01, > eg.married:true, > eg.childCount:123, > eg.custom:eg.datatype("value") > > Just so you know, I used a few RDFON shortcuts for xsd:date, > xsd:boolean, and xsd:integer. Those could have been the equivalent > full form: > > vcard.bday:xsd.date("1980-01-01"), > eg.married:xsd.boolean("true"), > eg.childCount:xsd:integer("123"), And for completeness, the standalone string value "stuff" is the short form of xsd:string("stuff"), and <http://www.example.com/> is the short form of xsd:anyURI("http://www.example.com/"). See where I'm going with this? In RDFON (and hopefully RDF 2.0), the whole concept of a "plain literal" drops out of the model altogether! (After replying to TBL in a separate email regarding RDFON, I only at this instant realize the significance of this!) Plain literals got into RDF because we didn't quite understand how we wanted to represent what programming languages call "primitive types", so you got a strange thing called a "literal" that couldn't have properties, didn't have a type (until they were added later), and just sort of floated around with a vague quasi-resource status (and interpreted differently in different contexts). At the time that may have been a good choice, based upon the then-current understanding of the problem. But I think we've had enough experience to allow us to refactor this. I've always had a dirty feeling ;) when working with RDF literals, but wasn't quite sure why. If nothing else, RDFON has allowed me to clarify the direction I'd like to go for RDF 2.0 regarding this issue. Thanks for letting me put my comments here as I try to get my thoughts together. Best, Garret
Received on Friday, 27 July 2007 00:05:46 UTC