Array of IRIs is not supported by playground and not specified in the spec

[lanthaler]

Look at the following example:

{
   "something" : { "@id":
      [
         "http://www.test.com/a",
         "http://www.test.com/b"
      ]
   }
}

I think the output should be:

_:bn <something> <../a>,
                 <../b> .

The playground fails to handle this. This case is similar to @list and should thus be supported. We might wanna support this also for @value:

{
   "something" : {
     "@value":  [ "a", " b", "c" ],
     "@language": "en"
   }
}

Strange enough this doesn't fail but produces the following Turtle output in the playgorund:

_:c14n0
   <something> "a, b,c"@en.

[gkellogg]

There's no provision in the RDF conversion algorithm for {"@id": ["a", "b"]} to generate multiple IRIs, Looking at step 3, the active subject and active property are passed in and then each value is handled in turn. As @id is not a property, there is no active property, so no triple to generate.

Some time ago, I considered that we might want to specify that using an array in this context would result in the value of the last item be used as the "return value" of the array, which could be used for defining the subject. Of course, this was in the context of @subject, not @id which has multiple meanings now. In any case, I couldn't see anything in the spec that would indicate that @id with an array value would really do anything, as @id is really different than a property or type.

As it happens, my implementation produces the following output, which agrees with Markus' interpretation:

[ <something> "http://www.test.com/a", "http://www.test.com/b"] .

But, it should probably be:

[ <something> <http://www.test.com/a>, <http://www.test.com/b>] .

We should definitely clarify this behavior, but I could see that this might be considered as producing multiple subjects as follows:

{
   "something" : { "@id":
      [
         "http://www.test.com/a",
         "http://www.test.com/b"
      ],
      "pred": ["1", "2"]
   }
}

What should that produce? You could see that it might be the following:

[ <something> <http://www.test.com/a>, <http://www.test.com/b>] .
<http://www.test.com/a> <pred> "1", "2" .
<http://www.test.com/b> <pred> "1" , "2" .

[lanthaler]

When I raised this issue I was primarily thinking about the object, not the subject. I think the following should be supported:

_This example contains an error sorry, please see next comments_

{
  "@id": "_:node1";
   "something" : { "@id":
      [
         "http://www.test.com/a",
         "http://www.test.com/b"
      ],
      "otherprop": ["1", "2"]
   }
}

This IMO should result in

_:node1 <something> <http://www.test.com/a>, 
                    <http://www.test.com/b> .
_:node1 <otherprop> "1",
                    "2" .

Gregg, could you elaborate why the output of your example should be

[ <something> <http://www.test.com/a>, <http://www.test.com/b>] .
<http://www.test.com/a> <pred> "1", "2" .
<http://www.test.com/b> <pred> "1" , "2" .

and not

_:xy <something> <http://www.test.com/a>,
                 <http://www.test.com/b> ;
     <pred> "1", 
            "2" .

[gkellogg]

This goes back to Manu's statement that this was examined and found to be too complex for JSON-LD. The idea was that this would be a way of specifying entities that have common properties and values. Niklas also described this as a use-case for his proposed @Rev keyword.

The thinking is that specifying an object with multiple @id entries is equivalent to describing multiple objects each with a singular @id having the identical key/value pairs, and that this was too complicated. In this specific case, the something property has as it's value on object with two @id values and an otherprop key also having two values. Associating the otherprop values with _:node1 would require promoting them to the object where _:node1 is defined, and I see no way to support this.

I suggest that we either dis-allow an @id with multiple values, or say that the value is that of the last element of the array.

[lanthaler]

Oh sorry, I just realized I made a mistake.. The example I wanted to put up above should be (so similar to @value with multiple values):

{
  "@id": "_:node1";
   "something" : {
      "@id":  [
         "http://www.test.com/a",
         "http://www.test.com/b"
      ],
   }
   "otherprop": ["1", "2"]
}

This IMO should result in

_:node1 <something> <http://www.test.com/a>, 
                    <http://www.test.com/b> .
_:node1 <otherprop> "1",
                    "2" .

[gkellogg]

The problem is, it's difficult to distinguish between the following:

{"@id": ["a", "b"]}

and

{"@id": ["a", "b"], "prop": "c"}

Both are object descriptions. If the first, when used as the value of another property, results in two entries, as you suggest, then how do we prohibit those from being two different subjects for the common "prop"? This gets into complicated territory. The easiest thing is to either prohibit the array form with @id, or define that it has a single value, being the last entry. This would mean that to specify what you want, we'd either need a coercion rule on "something", or the values would need to be expanded as follows:

{
  "@id": "_:node1",
  "something": [
    {"@id": "http://www.test.com/a"},
    {"@id": "http://www.test.com/b"}
  ],
  "otherprop": ["1", "2"]
}

Personally, I'm fine with this restriction. After all, you can easily define a term with @id coercion rules to get to a short form.

[lanthaler]

We could also just disallow the

{"@id": ["a", "b"], "prop": "c"}

It's basically the same as with @list. What happens if you have other properties in such an object? I think that should be disallowed as well:

{"@list": ["a", "b"], "prop": "c"}

[gkellogg]

The difference is that @list always ignores other keys, but @id would ignore other keys only when it is the value of another @id, this involves passing extra context information and complicates the algorithms.

Array order is only undefined for the generated triples, we can make use of JSON array ordering for the purposes of satisfying an algorithmic step. In this case, @id is described explicitly in the RDF conversion algorithm, so we can add a phrase such as "If the value is an array, process each item using step 2.5.2 and set the active object to the result."

The algorithm doesn't state this, but in my implementation, if the value is a JSON object, the active object is set to the result of performing the processing step, which returns the subject. This could be true for an array as well, if we define with the return result from the processing step is for an array; right now it's simply undefined.

[lanthaler]

Well, the difference to @list just appeared after we merged @subject and @iri to @id. So in principle we already have that extra context information in the algorithms, don't we?

Array order is only undefined for the generated triples, we can make use of JSON array ordering for the purposes of satisfying an algorithmic step

That might be easy to understand for us but I think a lot of authors without knowledge of all the algorithms and backgrounds would have a hard time understanding what's going on.. At the very beginning of the current spec we currently define an array as:

An array is an ordered collection of values. An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas. Within JSON-LD, array order is not preserved by default, unless specific markup is provided (see Lists). This is because the basic data model of JSON-LD is a linked data graph, which is inherently unordered.

Why should that then be different for @idarrays?

[msporny]

There are at least three reasons I'm against this sort of syntax:

{"@id": ["a", "b"]}

1. We may use it in the future to specify the setting of properties for multiple subjects. That is, if you add a property to the object above, both 'a' and 'b' would have that property.
2. Providing people with more than one way to do this creates confusion on the "correct" way to do it and adds complexity to the processor.
3. It doesn't really support any extra use cases - it's syntactic sugar that creates more complexity in the processor.

I think that we should do one of the following things when we hit markup like that found above:

1. Only use the first value in the @id array.
2. Only use the last value in the @id array.
3. Effectively do Basic: Focus more on Linked Data less on RDF #1 or Basic: What are relative URLs resolved against? #2 by modifying the @id value to only contain the first/last value.
4. Throw an exception/error.

I think we should do #3. My preference is to use the first value in the @id array because if we ever want to support setting values for multiple subjects at the same time, we keep the door open for that functionality. Thoughts?

[lanthaler]

OK, good point.. if we wanna keep the door open for something like that I think we should do #4, throw an exception.

All the other options would potentially create invalid data after a spec update. If we throw an exception now, we can change it to whatever we like afterwards as it won't affect existing data..

So, +1 for # 4

[msporny]

RESOLVED: If a string is found in an array that is the value of the "@id" key, a JSON-LD Processor MUST throw an exception.

Note: .. also expecting that we're moving away from arrays in @id for multiple subjects as well (when we come to that issue)

[gkellogg]

Use of @graph described in 9885ffe

[lanthaler]

I close this issue as it is not relevant anymore. The value of @id MUST be a string now.