Re: Issues with disjoint graph modelling

Hi

On Wed, Aug 3, 2011 at 2:34 AM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
>
> Sent from my iPad
>
> On Jul 31, 2011, at 5:09 AM, "Alexandre Passant" <alex@seevl.net> wrote:
>
>> Hi,
>>
>> I like the idea of disjoint graphs exposed in 9.2. and that's definitely useful.
>> Yet, I'm not convinced by the use of @ to express this.
>>
>> {
>>  "@":
>>  [
>>    {
>>      "@": "http://example.org/people#john",
>>      "a": "foaf:Person"
>>    },
>>    {
>>      "@": "http://example.org/people#jane",
>>      "a": "foaf:Person"
>>    }
>>  ]
>> }
>>
>> It's IMO confusing and we should come up with another term, such as
>> @data (and allowing override - cf my previous e-mail) for the first
>> one - as is not a subject per-se, but just a way to encapsulate the
>> others.
>
> Be it "@": [] or "@subject": [], much of these forms fall out of the general processing rules, such that every call to process an entity return a value that can be used as a subject. Otherwise, we end up adding special cases, where.none are necessary.

It was probably not clear - I'm not asking to add special cases, but
just found confusing the use of @ / @subject where it does not define
the subject of a triple. But that eventually works fine with
overloading (that's how we've done it in [1] with the use of @data)

>
>> Also, regarding the alternative form:
>>
>> [
>>  {
>>    "@": "http://example.org/people#john",
>>    "a": "foaf:Person"
>>  },
>>  {
>>    "@": "http://example.org/people#jane",
>>    "a": "foaf:Person"
>>  }
>> ]
>>
>> This one cannot accomodate context (you cannot add a @context:{}
>> inside the [] since it expects {} values). It may be a problem if
>> someone uses it and then realise that context must be added - this
>> requires to refactor the JSON and it will break the existing model. I
>> do not think it brings much compared to the first one, and IMO could
>> be dropped.
>
> The second form should be allowed, but as you point out, the first form my be required to add an @context.

It is probably good to add a warning in the spec. Something like
"Warning: This alternative serialisation does not allow to specify a
particular @context in the data file".

>
> I favor regularity in the processing rules. @data could be handled as a pseudonym for @subject using the term mechanism, but I would resist adding specific processing instructions for it.

+1

Alex.

[1] http://developers.seevl.net/wiki/explain

>
>> Alex.
>>
>> NB: If these issues should be raised on github rather than the ML, let
>> me know. I'm also happy to contribute to some of the fixes / editing.
>
> This is a great forum, and can also be added as a telecom subject.
>
> Any help with the docs is, of course, appreciated.
>
> Gregg
>
>> --
>> Dr. Alexandre Passant - @terraces
>> Founder, CEO - seevl.net - @seevl
>> Reinventing Music Discovery
>>
>



-- 
Dr. Alexandre Passant - @terraces
Founder, CEO - seevl.net - @seevl
Reinventing Music Discovery

Received on Thursday, 25 August 2011 18:11:56 UTC