Re: Representing RDF Literals/Resources as JSON Strings

Many thanks for this, Ian. Very interesting. Though ...

I guess what I was really after was something where the typing of the
literal and/or resource would be implicit in the syntax (as in N3/Turtle)
rather than explicitly broken out (as in XML), i.e. A concise
"human-readable" (and -writable ;) syntax. For example, N3 uses '"' to
delimit strings, '<', '>' to delimit URIs, etc. And with JSON we have the
constraint that primitive (unstructured) values should be presented as
strings (in double quotes).

Cheers,

Tony

ps/
Btw, where do all these Notes and WD's etc. come from? Hadn't seen this
before but maybe I just missed it. I am all wired up to the W3C feed but
somehow...


On 7/6/07 10:47, "Ivan Herman" <ivan@w3.org> wrote:

> Tony,
> 
> the only example that comes to my mind is the W3C note
> 
> Serializing SPARQL Query Results in JSON
> http://www.w3.org/TR/rdf-sparql-json-res/
> 
> maybe it gives you some inspiration...
> 
> Ivan
> 
> Hammond, Tony wrote:
>> Hi:
>> 
>> I am making use of JSON to map an RDF profile but am wondering how best to
>> represent RDF literals and resources as JSON strings.
>> 
>> Leaving aside blank nodes and numeric/boolean literals, N3/Turtle makes a
>> clear syntactic distinction between the following four kinds of values:
>> 
>>     * literal = quotedString | datatypeString
>> 
>>       1. quotedString = '"' string '"'
>> 
>>       2. datatypeString = quotedString '^^' resource
>> 
>>     * resource = uriref | qname
>> 
>>       3. uriref = '<' uri '>'
>> 
>>       4. qname = prefix ':' name
>> 
>> With JSON all (simple or primitive) values are (double) quoted strings. One
>> possibile syntax might be the following:
>> 
>>       1. quotedString = '"' string '"'
>> 
>>       2. datatypeString = ??
>> 
>>       3. uriref = '"' '<' uri '>' '"'
>> 
>>       4. qname = '"' '<[' prefix ':' ']>' '"'
>> 
>> with qname here taking a cue from CURIE's.  (Alternatively one could treat
>> qname the same as uriref and disambiguate depending on whether a prefix
>> namespace was declared.)
>> 
>> So, #1 is a natural match, #3 is passable, #4 is heavier but still a
>> possibility, and �2 ... well, I just don't know.
>> 
>> Was wondering if anybody else had done some work in this area and arrived at
>> any conclusions.
>> 
>> Cheers,
>> 
>> Tony
>> 
>> *****************************************************************************
>> ***   
>> DISCLAIMER: This e-mail is confidential and should not be used by anyone who
>> is
>> not the original intended recipient. If you have received this e-mail in
>> error
>> please inform the sender and delete it from your mailbox or any other storage
>> mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
>> liability for any statements made which are clearly the sender's own and not
>> expressly made on behalf of Macmillan Publishers Limited or one of its
>> agents.
>> Please note that neither Macmillan Publishers Limited nor any of its agents
>> accept any responsibility for viruses that may be contained in this e-mail or
>> its attachments and it is your responsibility to scan the e-mail and
>> attachments (if any). No contracts may be concluded on behalf of Macmillan
>> Publishers Limited or its agents by means of e-mail communication. Macmillan
>> Publishers Limited Registered in England and Wales with registered number
>> 785998 
>> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>> *****************************************************************************
>> ***
>>

Received on Thursday, 7 June 2007 12:14:49 UTC