Re: RDFON: a new RDF serialization

Hi Garret,

don't take my criticism as criticism of your new syntax for  
expressing RDF. If it brings on other people it may be helpful. On my  
blog post "the limitations of JSON" [1] I just got wind of a attempt  
to create an RDF semantics for JSON called JDIL [2].

Some questions on RDFON:

   In OO programming languages the "." operator usually applies a  
relation directly to an
object. So

    joe.getName().length()

in Java will give the length of the name of the person. N3 has a  
similar notation

    :joe.foaf:name.str:length

You use the . notation for separating the prefix from the name, which  
I find confusing. Well I suppose java does this too with the package  
notation java.lang.String.length ...

How would your language deal with multiple inheritance?


[1] see the last comment at http://blogs.sun.com/bblfish/entry/ 
the_limitations_of_json
[2] http://jdil.org/


More responses below:

On 27 Jul 2007, at 17:50, Garret Wilson wrote:

> Henry Story wrote:
>>
>> _:123 xsd:integer "123" .
>>
>> Which is to say that there is a thing, which has relation  
>> xsd:integer to the string "123".
>> my guess is that the relation xsd:integer, is inverse functional  
>> and functional.
>
> But I disagree with this. Does this thing also have a relation  
> xsd:integer to the string "one hundred and twenty three"? The  
> string "123" is an identifier---no more no less. The *only*  
> relationship the string "123" has to _:123 is  
> eg:oneOutOfTheManyWaysHumansRepresentThisValueUsingUnicodeCharacters.

It would not have the xsd:integer relation to "one hundered and  
twenty three", but
it could have another relation to that

[] en:numberInEnglish "one hundred and twenty three";
    morse:intcode "_...." ;
    xsd:integer "123" .

I don't see the problem here.

>
>>
>> Now I am not sure if in this case the blank node refers to itself.  
>> I suppose some (Bertrand Russle for example) would say it refers  
>> to the set of sets of size 123, just as 2 refers to the set of  
>> pairs, and 3 refers to the set of triples. But I am not sure how  
>> one should think of it in rdf.
>
> Funny---30 minutes ago having breakfast I was thinking of exactly  
> the same point, because it illustrates again how RDF uses literals  
> for various unrelated cases. Integers are completely different  
> things than URIs, somewhat different than dates, and parallel to  
> base 64 binary. RDF literals would also be appropriate for Java  
> enum types, such as MyColor.RED or PowerSetting.FULL. In short,  
> literals are used in RDF for everything we can think of that can  
> easily be represented by a string. The string is simply an  
> identifier. It refers to the resource, and that's the only  
> relationship it has to the resource.
>
> So I would rewrite your example:
>
> _:123 rdf:type xsd:integer .

That won't work. _:123 is a blank node, and so that is not saying  
very much. It could be any number. But of course you could do the  
following:

[] a num:Integer;
    en:numberInEnglish "one hundred and twenty three";
    morse:intcode "_...." ;
    xsd:integer "123" .

>>
>>
>> _:123 morse:intcode "_...." .
>
> I'm find fine with that (assuming that _:123 revers to the value  
> 8 ;) ).

Well I was assuming it refferred to the decimal integer 123. If not  
please forgive me, I know nothing of morse.

> We could also have:
>
> _:123 rdf:canonicalIntegerLexicalForm "123" . (Exaggerating the  
> name for emphasis)
>
> But the point is that "123" is not the resource. It's just one  
> representation of it.

Yes. I agree on that, right from the start.

>
>>
>>
>> [] morse:intcode "_...." ;
>>    xsd:integer "123" .
>
> I think you mean the same thing that I say above, but it's  
> confusing, because in XML Schema xsd:integer is a type. If you mean  
> rdf:canonicalIntegerLexicalForm or something, then fine. I want to  
> reserve xsd:integer to be the object of the rdf:type predicate.

You want to say

"123" a xsd:Integer .

That is wrong. "123" is a string.

but "123"^^xsd:integer a xsd:Integer .

would be ok.



>
> Garret

Received on Friday, 27 July 2007 16:38:24 UTC