Re: JSON-LD terminology

On 8/27/12 3:23 PM, Gregg Kellogg wrote:
> On Aug 27, 2012, at 11:52 AM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 8/27/12 1:25 PM, Gregg Kellogg wrote:
>>> Yes, we could add something that prohibits a key in a JSON-LD object from having the form of a BNode; I don't think this would really loose anything. The grammar in A.1 should say:
>>>
>>> [[[
>>> Keys are IRIs, compact IRIs, terms defined within the active context which MUST evaluate to absolute IRIs, or one of the following keywords
>>> ]]]
>>>
>>> or words to that effect.
>>>
>>> I would support removing that note, but I think the original came as a result of lobbying by Kingsley
>> Huh?
>>
>> Of what to you speak? Give me a link so I can put your comment in context that's easy for me to understand etc.
> Apologies for mis-attributing this; I know that you spoke out in favor of expanding the representation space of JSON-LD beyond just RDF [1]. I was working from memory, and there was definitely a reason we used SHOULD instead of MUST here.
>
> Researching the point, I see it was actually Glenn McDonald who objected to requiring that properties be IRIs [2]:
>
> [[[
> 8. A predicate should be represented as a URI.
>
> It should be possible to associate a predicate with an IRI, but I don't
> believe IRIs are very good *as* actual predicates, any more than they are as
> column-headings in a table, and even if you want to associate a predicate
> with an IRI, this is a model-level assertion that should be done once per
> type-arc, not once per instance assertion. And, in fact, I believe many,
> many data applications can function perfectly well without their arcs being
> formally meta-modeled at all.
> ]]]
>
> It seems to me, that out of this came the SHOULD description, and thus opened it to include BNodes, when the acutaly intention (I think) was to not require any binding at all. In fact, this can be done in JSON-LD, but properties (keys) that don't bind to absolute IRIs are discarded during expansion anyway.
>
> So, I think we can clear this up by saying that a property MUST be an IRI, and consistent with the general principle of allowing non-conforming data in JSON-LD, any properties that don't resolve to absolute IRIs are discarded.
>
>> Whenever I use the word "Key" its in the context of a DBMS key, and typically when analogizing the effects of a Linked Data style of de-referencable URI.
> When talking about JSON and JSON objects, the notion of "key" is well-understood.
>
> Remembering that you are a big advocate of having IRIs for everything, I'm not sure how I confused this. Apologies.

Phew!

Thanks for cleaning and clearing  that up :-)


>
> Gregg
>
> [1] http://lists.w3.org/Archives/Public/public-linked-json/2011Jul/0017.html
> [2] http://lists.w3.org/Archives/Public/public-linked-json/2011Jul/0016.html
>
>

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen