Re: RDFON: a new RDF serialization

Tim Berners-Lee wrote:
> On 2007-07 -26, at 17:11, Garret Wilson wrote:
>> (
>>    rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>,
>>    xsd:<http://www.w3.org/2001/XMLSchema-datatypes>,
>>    vcard:<http://www.w3.org/2006/vcard/ns#>,
>>    foaf:<http://xmlns.com/foaf/0.1/>,
>>    eg:<http://www.example.com/>
>> )
>> foaf.Person(<urn:uuid:ca00db92-0f7f-434b-b254-8a6afcf57907>)
>> {
>>    vcard.name:vcard.Name()
>>        {
>>            vcard.givenName:"Mary Jane",
>>            vcard.familyName:["Smith", "Van Buren"]
>>        },
>>    vcard.bday:@1980-01-01,
>>    eg.married:true,
>>    eg.childCount:123,
>>    eg.custom:eg.datatype("value")
>> }
>>
>> Isn't that beautiful?
>
> Well, I prefer:
>
>     @prefix : <http://www.w3.org/2006/vcard/ns#> .
>     @prefix eg: <http://www.example.com/#> .
>     @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>    
>     <urn:uuid:ca00db92-0f7f-434b-b254-8a6afcf57907>     a 
> <http://xmlns.com/foaf/0.1/Person>;
>          eg:childCount 2;
>          eg:custom "value"^^eg:datatype;
>          eg:married true;
>          :bday "1980-01-01"^^<http://www.w3.org/2001/XMLSchema#date>;
>          :name  [
>                 a :Name;
>                 :familyName  ( "Smith"  "Van Buren" );
>                 :givenName "Mary Jane"
>           ] .
>
> The only thing I notice you put in RDFON which we didn't put in N3 was 
> the literal date format.  
> You can't execute N3 as javascript, but that can be an advantage, 
> securitywise.

Although I've used RDF since the early days, I seem to have skipped a 
lot of the advancements made in serialization as my focus was distracted 
over the past few years. Sure, it appears that the difference between 
RDFON and N3 are negligible from a technical point of view, so I don't 
want to argue that one is better or worse than the other. I would like 
to point out a few merits of RDFON to think about.

    * RDF is built upon an assumption of propositional logic and
      category theory that many programmers aren't used to. Sure, it's
      the same philosophy underneath (going back to Wittgenstein,
      Russel, Frege, and even Aristotle), but many programmers think in
      different terms. N3 thinks, "I'm making an assertion regarding a
      particular subject, predicate, and object, so I therefore list the
      three parts of the proposition being asserted." 95% (I would
      guess) of today's programmers would think, "I'm assigning a value
      to the property of an object." So while N3 has "eg:childCount 2;",
      a procedural programmer sees something wrong here---he or she will
      breath a sigh of release when he/she sees that extra delimiter
      character separating the property from its value:
      "eg.childCount:2". This is a teeny, tiny issue, but I think the
      difference in mindset between "setting object properties" versus
      "asserting propositions" is a significant one, even though they
      both mean the same thing.
    * Along the same lines, when a common programmer looks at
      "<urn:uuid:ca00db92-0f7f-434b-b254-8a6afcf57907> a
      <http://xmlns.com/foaf/0.1/Person>" he/she won't know what the
      heck is going on. When he/she looks at
      "foaf.Person(<urn:uuid:ca00db92-0f7f-434b-b254-8a6afcf57907>)", on
      the other hand, he/she will think, "Ah, an instance of the class
      foaf.Person is being instantiated, and is being initialized with
      the URI <urn:uuid:ca00db92-0f7f-434b-b254-8a6afcf57907>, which
      must be its ID." Of course, that's not *exactly* what's going on,
      but at its core it's saying the same thing---and we've made it
      easier for the common programmer to grasp what's going on.
      (Frankly, there are a lot more common programmers out there than
      there are propositional logicians.)
    * So let's talk about literals, now. No one take offense, but I
      personally have always thought that "value"^^eg:datatype is just
      plain ugly. And it shows that RDF never quite knew what to do with
      literals, especially not typed literals. If everything is a
      resource and everything can be described by a three-part
      proposition, what is eg:datatype? Is it a property of the literal
      "value"? But literals can't have values. And surely the literal
      "value" cannot have multiple conflicting datatypes. And how is an
      xsd:string different from a plain literal? In RDF 2.0, I would
      like to move literals away from their strange quasi-resource
      status so that *everything* is a resource, For Real. An integer
      such as 123 is a resource, and it might be *defined" by the
      sequence of characters "123", but that's different than saying
      that "123" is a resource with a data type of xsd:integer (which is
      not true). I'd like to see something like <xsd:integer
      rdf:literalAbout="123"/>, where "123" plays an analogous role to
      rdf:about. This is the same thing has saying <rdf:Description
      rdf:type="xsd:integer" rdf:literalAbout="123"/>. Suddenly we get
      typed literals (distinct from strings!) that can take properties
      and appear in lists with no problem. And (finally) going back to
      RDFON, we see that eg:datatype("value") is really just
      instantiating an eg:datatype class with a lexical identifier
      instead of a URI identifier. It makes sense to common programmers
      using RDF 1.x, and it points to where I want to go with RDF 2.0,
      in which everything is a resource, For Real, and a typed literal
      is not just a kludge on top of a kludge.
    * Common programmers expect a comma in a list such as ( "Smith" 
      "Van Buren" ). Perhaps propositional logicians do not.


Again, my arguments for RDFON syntax over N3 are based upon other than 
technical merits. I can't say one is technically better than the 
other---but I do have a personal preference, as I've outlined, and I 
think common programmers will share my preference.

I'm sure my prelude to my new proposals for literals in RDF 2.0 will get 
some comments---just please be sure not to mix up that issue too much 
with the RDFON proposal---they are related but distinct.

Best,

Garret

Received on Thursday, 26 July 2007 23:53:27 UTC