Apply nesting to extensions and dublinCore

[PonteIneptique]

Fixes #280

This does not look good on JSON LD playground but this seems to be specs valid.

[hcayless]

I think we'll need to define dc:description, dc:identifier, and dc:title in the context of the dublinCore property, because of the name collisions:

"dublinCore": {
  "@id": "@nest",
  "@context": {
    "@vocab": "http://purl.org/dc/terms/",
    "description": { 
      "@id": "dct:description"
    },
    "identifier": { 
      "@id": "dct:identifier"
    },
    "title": { 
      "@id": "dct:title"
    }
  }
}

(with "dct": "http://purl.org/dc/terms/", up at the top of the @context) .

I think that's all of the potential conflicts. But might be worth checking.

[hcayless]

I've been wrestling with the idea of extensions a little, and I think we ought to (as the default) set the @vocab of extensions to null, thus:

"extensions": {
    "@id": "@nest",
    "@context": {
      "@vocab": null
    }
}

What this will do is make sure that a) content of extensions doesn't go in the DTS vocabulary, and b) doesn't get processed at all for RDF purposes. If implementers want to use extended metadata and have it be processed as RDF, they'll need to redefine it in their own context. For example, this is how you could put the content of extensions into the CIDOC-CRM vocab:

"@context": [
    "https://distributed-text-services.github.io/specifications/context/1.0.json",
    {
      "extensions": {
        "@id": "@nest",
        "@context": {
          "@vocab": "http://www.cidoc-crm.org/cidoc-crm/"
        }
    }
  }
]

If you don't care about RDF and just want to slap your own stuff in extensions, that's absolutely fine and RDF processors will ignore it. We should add a recipe or two (like the above) showing how to properly implement extensions.

Also, if we're going this route, we should probably set "@version": 1.1 in our context.

[monotasker]

I've been playing catch-up here and reading the spec, since my grasp of the JSON-LD issue was fuzzy. I'm convinced that the @nest approach is the way to go, and I like your suggestion @hcayless about setting @vocab to null. If people are adding other ontologies they should be able to include the vocabulary definition.

My only point of confusion is around the naming conflicts. This may still be a gap in my understanding. But if our top-level context collides with a term in the inner context's vocabulary, doesn't each term just get expanded with its own context's URI for that term? So "title" and "description" inside the dublinCore object would be expanded to "http://purl.org/dc/terms/title" and "http://purl.org/dc/terms/description", so the collision disappears? I suspect there's something I didn't follow in the discussion.

If there is a collision issue, though, then anyone using another vocabulary in extensions would need to bind those colliding terms--wherever their vocabulary produces collisions?

[hcayless]

@monotasker Re the naming conflicts: You would think that, but I believe the idea is that explicitly defined terms always win. If you've set the vocabulary but not defined the term used, then it will be in the vocab you set, but if you defined the term in another vocab, it will be in that vocab wherever it's used (unless you override the definition), meaning title will be a DTS title unless you redefine it to be a DC title in the scope of dublinCore. And yes, that's probably something we should discuss in the recipe because it's confusing.