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

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"
 }



> 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 17:45:28 UTC