- 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