W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re: RDFON: a new RDF serialization

From: Henry Story <Henry.Story@Sun.COM>
Date: Fri, 27 Jul 2007 08:47:14 +0200
To: Garret Wilson <garret@globalmentor.com>
Cc: Semantic Web <semantic-web@w3.org>
Message-id: <F12A2041-EB5B-4966-84A2-929C9AB2A9FC@Sun.Com>


On 27 Jul 2007, at 02:05, Garret Wilson wrote:
> 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.

Sometimes I think it was the XML serialization that made literal  
types seem natural. The string always comes after the angle brackets...

I also wonder if the model would not be even simpler if you did not  
have the restriction that literals have to the object of a relation.

But I think literals do serve a purpose as opposed to URLS. They are  
things that refer to themselves, as opposed to URI's that refer to  
other things.

> 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.

As I understand N3 does in fact allow you to say things like this

"2"^^xsd:integer = 2 .

2 a :Number .
2 :plus ( 1  1 ).

Whether that should be part of Turtle and so part of SPARQL is an  
interesting question.


> Thanks for letting me put my comments here as I try to get my  
> thoughts together.

It is going to be very difficult to proove that one of these  
serialization formats is more intuitive than the other. I have not  
had trouble teaching people RDF in less than an hour
by going through the following steps:

   - making the notion of a relation intuitively obvious by having  
people imagine an arrow going from one thing to the other
   - starting with NTriples to show how it is all just relations
   - showing how that could be abbreviated with syntactic sugar in  
Turtle,
   - and then moving on perhaps to N3.

Now I did not test how well people understood that, but they are  
never too frightened.

There is a danger of being too close to something people think they  
understand, because that can mislead them into thinking there is  
nothing different. And there is going to be something quite different  
here from OO programing, namely something that is ready for use with  
inferencing machines.

Anyway, if you found a way of testing your thesis that would be  
interesting...


> Best,
>
> Garret



Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me
Received on Friday, 27 July 2007 06:47:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:26 UTC