Re: Can JSON-LD cater for Talis' RDF/JSON design goals?

On 30/08/11 18:59, Richard Cyganiak wrote:
> On 30 Aug 2011, at 17:59, Steve Harris wrote:
>> On 2011-08-30, at 13:57, Richard Cyganiak wrote:
>>> On 30 Aug 2011, at 08:56, Steve Harris wrote:
>>>>> Could JSON-LD be changed so that one can define an “RDF geek
>>>>> compatibility context” that directly results in this
>>>>> convenient form, without need for post-processing?
>>>>
>>>> That immediately makes me think of the "XML friendly" striped
>>>> syntax of RDF/XML, i.e. hurts everyone, all the time.
>>>
>>> I asked whether we can get a profile of JSON-LD that's isomorphic
>>> to Talis RDF/JSON. You'll have to expand a bit on why that would
>>> hurt everyone, all the time.
>>
>> Because it would be a "special profile" of JSON-LD, just like
>> RDF/XML is a special profile of XML, or RSS 1.0 was a special
>> profile of RDF/XML. Though RSS had a schema, so it's a little less
>> painful.
>
> These are completely different things.
>
> The “triple-friendly profile for JSON-LD” would be like a profile for
> RDF/XML that forbids all the optional variants so that there is just
> a single way of expressing an RDF graph as an XML tree (modulo
> ordering). Which would have been quite handy -- then you could
> *almost* write triple pattern queries with simple XPath (except for
> namespace prefixes and relative URIs).
>
> I want an RDF in JSON variant that allows me to write a triple
> pattern query in a simple JSON expression.

Richard,

Ian noted that the RDF/JSON format has indexing by subject (via the top 
JSON object).  JSON-LD of more than one subject uses nesting/framing or
an array of JSON objects.  In an “RDF geek" profile, presumably there is 
only one way which has to be the array form. The array is marked 
"experimental" but it's necessary if JSON-LD is to represent any RDF 
graph AFAICT.

Would (1) either of the different layouts (2) the need to loop sometimes 
meet your "simple JSON expression" criterion?

	Andy

Received on Tuesday, 30 August 2011 18:30:12 UTC