Re: Representing RDF Literals/Resources as JSON Strings

Tony,

Hammond, Tony wrote:
> 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).
> 

I understand. Personally, I am not 100% sure that this is the best
approach, though. The beauty of json is that it is very easy (shall we
say, trivial) to parse it in, say, Python (which is my preferred
language) and if you try to put too much into a single literal then an
extra parsing step is necessary for the program using it. That may be
more complicated than interpreting the separate information pieces on
URI-s and others. But this is a personal choice...

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

I cannot answer for W3C as a whole. The Semantic Web activity maintains
its own activity news in the form of a blog:

http://www.w3.org/2001/sw/anews/

which (of course:-) has its own RSS feed. The news on the JSON stuff was
in October:

http://www.w3.org/blog/SW/2006/10/05/sparql_query_results_in_json

Ivan

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

-- 

Ivan Herman, W3C Semantic Web Activity Lead
URL: http://www.w3.org/People/Ivan/
PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf