Let @vocab take precedence over compact IRIs in compaction

[niklasl]

If a @vocab mapping is given, compaction should use that to avoid creating a compact IRI for a term. The purpose of compaction is to make the results as simple and usable as possible, and consumption of JSON with CURIE terms is problematic and undesirable. I propose that @vocab is considered prior to making a compact IRI.

That means moving the content of step 6 before step 3 in 8.3 IRI Compaction of the Processing Algorithms. And to rewrite the initial text of that section to something like:

"If no term was found that could be used to compact the IRI, then an attempt is made to construct one based on the active context's vocabulary mapping, if there is one. If no such term can be constructed, then an attempt is made to find a compact IRI. If there is no appropriate compact IRI, the IRI is transformed to a relative IRI using the document's base IRI. Finally, if the IRI or keyword still could not be compacted, it is returned as is."

That would ensure that this data:

{
  "@type": "http://schema.org/Document",
  "http://schema.org/name": "Something"
}

when compacted with this context:

{
  "@context": {
    "schema": "http://schema.org/",
    "@vocab": "http://schema.org/"
  }
}

results in:

  {
    "@type": "Document",
    "name": "Something"
  }

(Of course, we must ensure that this has no unexpected consequences. It doesn't seem so, but the change should be verified with an implementation against the test suite.)

[lanthaler]

I just verified it. The only test that would need to be changed is compact-0023 (context): "Prefixes have precedence over @vocab - even if the result is longer"

AFAICT it won't have any desired side-effects. If you want to compact something to prefixes, you just have to reset @vocab by setting it to null which is, as Niklas argued in his mail, simpler than resetting a number of prefixes.

So, I think I'm +0.9 on this.

[dlongley]

Can we try listing the reasons why anyone would have both @vocab and a matching prefix in a context? That might help us decide what the best behavior would be.

1. To shorten term definitions by using CURIEs. (Since vocab terms can be used on the RHS in the context, they are an even shorter alternative to CURIEs. But I guess the argument here is that it may look odd or is confusing?)
2. To properly expand terms in the data that aren't defined (here we can think of it as if we added @vocab only to ensure we capture certain data).
3. To properly expand CURIEs in the data (so they aren't confused w/absolute IRIs) when you're actually using terms in most places (here we can think of it as if we added the prefix only to ensure we capture certain data).

For case 2, we probably would prefer to use CURIEs when compacting. If CURIEs are preferred over @vocab, we don't have to make any context changes. If @vocab is preferred over CURIEs, then we'll have to compact with a context that sets @vocab to null. If any term definitions depended on @vocab, those will also have to be changed -- this can be more difficult than just setting @vocab to null, but is perhaps unlikely to happen.

For case 3, we probably would prefer to use terms when compacting. If @vocab is preferred over CURIEs, then
we don't have to make any changes. If CURIEs are preferred over @vocab, then we'll have to compact with a context that sets the prefix to null. If any term definitions depended on CURIEs, those will also have to be changed -- this can be more difficult than just setting the prefix to null and may be likely to occur.

So far, it sounds like there's an argument that it would be more likely for someone who wanted to compact to terms to also use CURIEs (just in the context) rather than the other way around. If that's true, then we should prefer @vocab over CURIEs because it is the simpler solution in the common case.

Are there other reasons for mixing @vocab with a prefix for the same IRI?

[lanthaler]

As I understood Niklas the use case is if you include a remote context defined a number of well-known prefixes. It could well be that, e.g., the RDFa initial context is used or that we host something else somewhere at W3C in the future. You would then reference that “generic” remote and augment it with some local definitions, such as @vocab. You would like that this @vocab takes precedence over the prefixes defined in the generic context.

Think, most of my data uses schema.org but I also use some FOAF, XSD etc. I would then simply reference the remote context and add a @vocab set to schema.org so that most IRIs are compacted to terms instead of compact IRIs.

[lanthaler]

RESOLVED: When compacting IRIs @vocab should take precedence over Compact IRIs. This reverses the previous order of precedence.

[lanthaler]

I've updated the API spec and the test suite so that @vocab takes precedence over compact IRIs in compaction. Unless I hear objections, I will thus close this issue in 24 hours.