Re: RDFON: a new RDF serialization

Henry Story wrote:
>
>   In OO programming languages the "." operator usually applies a 
> relation directly to an
> object.
...
> 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 ...

Remember that this RDFON "proposal" is not finalized---in fact, 
yesterday morning is the first time I ever wrote anything down, although 
I've been thinking about a better RDF syntax for years. I wanted to post 
this to the list while the interest was still hot.

When I was jotting this down, I first changed from '.' to '#' for 
exactly the reason you noted: confusion from programming language 
property notation. I switched it back at the last minute, thinking 
specifically of Java package notation. But I'm not set on '.'---I may 
decide something is better. In fact, in RDF 2.0 I'd like to change the 
relation between namespace URIs and resource URIs (that's another 
subject), so '#' might be the correct delimiter in the end.

>
> How would your language deal with multiple inheritance?

RDFON is not a language. It's a serialization format for RDF. Answer the 
question, "How does RDF deal with multiple inheritance?" and you have 
the answer.


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

See my later comment. If you're using xsd:integer to be a type 
predicate, I disagree. If you're using xsd:integer to mean 
en:numberInDigits, I agree completely.


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

"That won't work" is not the same thing as "that is not saying very 
much." Of course it will work, but it's not saying very much. ;) I 
assume that there are other statements indicating the resource URI as 
<rdfliteral:123;xsd:integer> or something. But my *only* point here is 
that I see xsd:integer to be the type of a normal resource---not just 
some strange appendix to a string.


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

Again, if you start using eg:intDigits or something instead of 
xsd:integer, I'll be happy. Perhaps we mean the same thing, but this 
will confuse people to no end. How about this:

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


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

I don't know Morse Code either---I just did a Google search and found 8 
before I found 123, so that's what I used. ;)

>
> You want to say
>
> "123" a xsd:Integer .

Hmmm... don't think I ever said that. See the representation above after 
"How about this?"

>
> That is wrong. "123" is a string.

Completely agreed.


>
> but "123"^^xsd:integer a xsd:Integer .
>
> would be ok.

Yeah, I think we're talking close to the same thing here. Let me update 
the example above:

<rdfliteral:123;xsd:Integer> a xsd:Integer;
   en:numberInEnglish "one hundred and twenty three";
   morse:intcode "_...." ;
   eg:intDigits "123" .

Then in RDF/XML, the following serialization:

<eg:property rdf:datatype="xsd:integer">123</eg:property>

Would automatically produce the correct URI and give something like this:

<rdfliteral:123;xsd:Integer> a xsd:Integer;
   rdf:canonicalLexicalRepresentation "123" .

And now we have resources that act like other resources, we know it's 
type, and we even know how to represent it as a string. But we only know 
*one* way to represent it as a string; Pakistan and India would use 
different representation in Urdu and Hindi, respectively. We only know 
the canonical programmatic representation that was used in this 
serialization. In fact, rdf:canonicalLexicalRepresentation is so closely 
tied to serialization forms that use Unicode that I'd almost say throw 
out the rdf:canonicalLexicalRepresentation as well. But I'm not sure 
about that.

In RDFON, you could do either of the following:

xsd:Integer("123")

or

xsd:Integer(<rdfliteral:123;xsd:Integer>)

And they would both result in the same RDF data model. See why I say 
that RDFON is a serialization distinct from any new RDF proposal, but it 
more naturally indicates new features I want to see in RDF 2.0?

Best,

Garret

Received on Friday, 27 July 2007 17:15:58 UTC