Re: Limitations on JSON which conforms to JSON-LD spec?

> On Dec 2, 2014, at 9:44 AM, James M Snell <jasnell@gmail.com> wrote:
> 
> On Tue, Dec 2, 2014 at 9:17 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> [snip]
>> 
>> I think I mentioned on another thread that there’s an open issue for this
>> [1]. @index only works when you have property values which would otherwise
>> be in an array and you want to use an object to index them.
>> 
>> The ability to index nodes which would otherwise be in an array would be a
>> useful extension. There are two use cases I had in mind:
>> 
>> A top-level “@container”: “@id” in a context would indicate that the keys of
>> the object containing the @context would be treated as @id values of the
>> nodes they reference. For example:
>> 
>> {
>>  “@context”: {“@container”: “@id”},
>>  “a”:  {“b”: “c”}
>> }
>> 
>> would be the same as
>> 
>> {
>>  “@id”: “a”,
>>  “b”: “c”
>> }
>> 
> 
> This is problematic in that the labels would typically not expand into
> URI's. The index tends to be more of a label (rdfs:label?
> skos:prefLabel?)
> 
> {
>   "rdfs:label": "a",
>   "b": “c”

Yes, of course, I was simply sketching out how this might work. Certainly all terms would need to property expand. If there’s interest, we can try to develop these ideas further, They really need discussion with the wider community (Dave? Markus?), as there may be other ideas, and the algorithms will need to be thought out.

In my copious free time :P I may work on my own implementation of what I describe here.

Gregg

> } 

>> The second proposal was to create a @reverseindex, which would treat the key
>> as an index to the properties it contains, effectively making it go away.
>> For example:
>> 
>> {
>>  “@context”: {“properties”: {“@container”: “@reverseindex”}},
>>  “@id”: “a”,
>>  “properties”: {
>>    “b”: “c”
>>  }
>> }
>> 
>> would turn into something like the following:
>> 
>> {
>>  “@id”: “a”,
>>  “b”: {“@value”: “c”, “@reverseindex”: “properties”}
>> }
>> 
> 
> Again, the challenge here is that "b" is not defined in a context and
> would not expand out. Given the input...
> 
> {
>  “@context”: {
>    "properties": {
>      "@id": "urn:example:properties",
>      "@container": "@index"
>    }
>  },
>  “@id”: “a”,
>  “properties”: {
>    “b”: “c”
>  }
> }
> 
> which becomes...
> 
> {
>  "@id": "a",
>  "properties": [
>    { "@index": "b", "@value": "c" }
>  ]
> }
> 
> and expands out to
> 
> <a> <urn:example:properties> [
>  a rdfs:Literal ;
>     rdfs:label "b" ;
>     rdf:value "c" .
> ] .
> 
> The nice thing is that it would not require any syntax changes to
> JSON-LD (The change to support this would be limited to the JSON-LD
> algorithms).
> 
> - James
> 
>> We’re likely a ways from a formal update to JSON-LD, but the community could
>> decide on informal extensions such as this through the CG. Of course,
>> there’s quite a bit of work involved in hashing these out and getting
>> reasonable spec text and tests to adequately define them.
>> 
>> Gregg
>> 
>> [1] https://github.com/json-ld/json-ld.org/issues/246
>> 
>> regards,
>>     Jauco
>> 
>> On Tue, Dec 2, 2014 at 12:57 AM, ☮ elf Pavlik ☮
>> <perpetual-tripper@wwelves.org> wrote:
>>> 
>>> On 12/02/2014 12:17 AM, Nicholas Bollweg wrote:
>>>> As we have seen a number of times here on the list, objects made from an
>>>> unknowably large set of of keys are hard to do anything compelling
>>>> with... see package.json//dependencies/,
>>>> ipython.ipynb//cells/output/data/.
>>> I think I understand. What in plain JSON people may tend to structure as
>>> object with keys and values. In JSON-LD people would use array of
>>> objects instead.
>>> 
>>> I've send emails lately here about it: "using object keys in JSON-LD"
>>> http://lists.w3.org/Archives/Public/public-linked-json/2014Oct/0004.html
>>> 
>>> To my understanding, JSON-LD Data Indexing (which Markus pointed me to
>>> on thread above), provides a useful construct for those cases.
>>> http://www.w3.org/TR/json-ld/#data-indexing
>>> 
>> 
>> 
>>

Received on Tuesday, 2 December 2014 23:46:22 UTC