Expand @type to @id-objects

[lanthaler]

Recently we changed the behavior of expansion to expand basically everything to object form, except @type which remains (becomes) a string. I would be fine with that if we don't accept an input in the form of "@type": { "@id": "ex:type" } but in the last telecon there seemed to be agreement that we should allow that form.

I think it would thus just be consequent to treat @type as every other property and expand it to object form. This would us allow to eliminate some code in expansion, compaction, and probably also in framing.

As we already opened this door, I think we should go even further and allow what @niklasl wanted to have some time ago, i.e., support things like:

 ...
  "@type": {
    "@id": "http://example.com/type",
    "label": "Type name",
  }

(This issue was originally raised in #115 were we changed expansion)

[dlongley]

I think allowing @id in @type is a corner-case and it should therefore be treated as such.

[dlongley]

That being said, if most people want this changed, I won't stand in the way. I wouldn't mind reducing code complexity here.

[gkellogg]

One argument against this is that @id must be absolute, and. It relative, and would work with a potential @vocab. Putting it in an object wouldn't help. However, we should allow @type to be aliases when expanding, so we should accept the expanded form.

[lanthaler]

Gregg, your comment is a bit difficult to understand. The value of @id can as well be a relative IRI, it doesn't have to be an absolute one. The concern regarding @vocab is valid but I think that wouldn't really be show-stopper. Except (en)force the value @type to be a string (or an array of strings). But if I remember correctly there's at least one testcase which uses @id already. I would be fine either way:

• don't expand @type to @id-objects and just allow the value to be string or an array of strings
• expand @type to @id-objects and allow the value to be a string, a subject def./ref. or an array of a combination thereof

I don't see a point of allowing @id-objects as value and not expanding @type to that form though (which is basically the same as compacting the value in expansion).

[gkellogg]

If we consider that there are really two different types of IRIs, those that relate to the resource itself, where it makes sense for them to be document relative, and those that are part of the vocabulary, where relative IRIs do not make sense, this helps provide guidance. @type has the range of vocabulary IRI, and can't be relative. If we encourage the use of expanded subject-reference form for expanding @type, we get one further step away from this designation, considering that every other time you use the @id form it may be a relative IRI.

That said, we do want to allow documents that might have @id expanded form to be coerced to an @type on compaction.

These are obscure issues, and the language would still hang together if we use expanded @type form, but keeping it the way it is helps highlight the different type of IRI being used.

[lanthaler]

Just a quick reply.. I'm not sure all of us agree that @type can't be relative - am I wrong?

[niklasl]

In general I don't think @type should support relative references if it is chosen from the same space as properties. This "vocabulary space" should be separated from the "application space" of resource IRIs (as it is in all syntaxes I know of using IRIs for symbol identifiers, such as all RDF serializations, and Atom). I believe the two prime reasons for this are:

• Vocabulary symbols are commonly orthogonal to described things. It's not desirable that every data publisher invents local symbols for things (to avoid the Babel effect).
• This separation makes it crystal clear that terms are not relative segments. (In most systems, these spaces do not overlap. In RDFa, for pragmatic reasons, there are two overlaps: CURIEorIRI and TermorCURIEorAbsIRI.)

That said, it may be the case that JSON-LD already breaks these principles by allowing terms to override non-dot-slash-prefixed relative IRIs in @id? When we removed @vocab and @base I figured that was mitigated since I mistakenly thought it meant no relative IRIs allowed. Since it seems we do allow such things, but without any means of explicitly setting @base, I wonder if these principles should be brought up and compared to our current situation?

[gkellogg]

I think it comes down to if we are going to support @vocab. If so, them maintaining a clean separation. Steepen application and property spaces really suggests that we keep the rules for @type separate from other subjec references. Otherwise, we could achieve some simplification. By using subject references uniformly, and drop the special "parameter space" requirements.

For my part, I think we need @vocab and should keep the syntax distinct.

[lanthaler]

@niklasl could you point me to where in Atom IRIs use a different base IRI?

[gkellogg]

RESOLVED: When operating on @type, the result of the expansion algorithm MUST always result in an array of strings that are IRIs.

RESOLVED: In the expansion algorithm, when expanding the value associated with @type, extract only @id from that value. Any value that does not expand to an absolute IRI MUST be discarded.

This allows input forms to use object, but extracts only the @id from those objects on expansion.

[lanthaler]

I've read the minutes (but didn't listen to the audio yet) and don't really understand what the reasons are to allow @id objects at all in @type if we throw everything but the IRI away? I think this is a dangerous decision - it's effectively a lossy compaction during expansion.. quite confusing and I wouldn't know how to explain that to someone.

[lanthaler]

I agree with almost everything that was said and decided on the call two
weeks ago except the following

RESOLUTION: In the expansion algorithm, when expanding a value associated
with @type that is a JSON object, extract only @id from that value. Any
value that does not expand to an absolute IRI MUST be discarded.

It is kind of a contradiction to argue that @type should not be expanded to
@id-form because they have different IRI-spaces but then take @id out of an
object and use it as it would have been a string value for @type.
Furthermore I always get a bit nervous when data is thrown away without any
notice or error.
I don't really understand why we need to support objects for @type at all!?
What are the use cases? The only reason I see is to support data coming from
RDF and representing it in a very specific way and that's already covered by
using something like

"type": "rdf:type"

in the context.

So I would suggest we do NOT allow objects as values of @type at all. In my
opinion there are just too many corner-cases to design it in a way that is
understandable and interoperable (no @id, @value objects, another @type
object, automatically create a blank node or not, etc.)

[lanthaler]

This was further discussed in the 2012-06-26 telecon but we run out of time and didn't decide yet whether we support objects as value of @type or not. The use cases are not clear (do we have any?) and we potentially discard data which we shouldn't without triggering an error IMO.

[lanthaler]

RESOLVED: When @id is found as a value in an object associated with @type, a handler callback is called to handle the issue.

To clarify - the handler callback is called whenever any "non-conforming" data is found.