remove @vocab and hydra prefix from JSON-LD context

[elf-pavlik]

In response to #15

Introduced changes ensure that framed content for hypermedia interface will always have full IRIs and not CURIEs with hydra: prefix or plain terms from the hydra @vocab.

This assumes relying on hydra helper from namespaces module. At the same time I would like to understand better advantages of relying on that helper instead of keeping hydra: prefix in JSON-LD context and rely on use of CURIEs hydra.Collection (helper) vs. "hydra:Collection" (CURIE)

---

This change is 

[lanthaler]

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

src/DataModel/JsonLd/context.json, line 2 at r1 (raw file):

{
    "@context": {

There's a trick which allows you to avoid having to use the full URL all the time. You can layer two contexts on top of each other; the second one just gets rid of the prefix:

  "@context": [
    {
      "hydra": "http://www.w3.org/ns/hydra/core#",
      "operations": "hydra:operation",
      ...
    }, { 
      "hydra": null
    }
  ]

---

Comments from Reviewable

[elf-pavlik]

Review status: 1 of 2 files reviewed at latest revision, 1 unresolved discussion.

---

src/DataModel/JsonLd/context.json, line 2 at r1 (raw file):

Previously, lanthaler (Markus Lanthaler) wrote…

There's a trick which allows you to avoid having to use the full URL all the time. You can layer two contexts on top of each other; the second one just gets rid of the prefix:

  "@context": [
    {
      "hydra": "http://www.w3.org/ns/hydra/core#",
      "operations": "hydra:operation",
      ...
    }, { 
      "hydra": null
    }
  ]

Done.

---

Comments from Reviewable

[lanthaler]

if no one objects, I'll merge this in the next couple of days

---

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[alien-mcl]

As for the change - indeed it's a bit cleaner, but I was wondering whether changing an explicit declaration (which is a trick) with another trick that seems somehow difficult to understand is a good way.
As for the question regarding hydra helper - it's purely for code readability and to avoid string literals flying here and there. We could have a list of constants defining each term IRI, but I thought that having a hierarchy of IRIS arranged with constant names relating to original prefixes are a better way. It has nothing to do with the JSON-LD context and it's purely for TypeScript/JavaScrpt readability while accessing some of the JSON-LD originating Javascript objects.

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[elf-pavlik]

To my understanding this context only gets used by JSON-LD hypermedia processor in framing the "hypermedia interface". Developers using the client only need to rely on that interface and don't need to know anything about this context and framing done internally to create the "hypermedia interface".
I would like after merging this one to still leave #15 open for further conversations.

---

Comments from Reviewable

[alien-mcl]

It can be used elsewhere, but it's a list of URLs- nothing more, nothing less and has nothing to do with the internally used JSON-LD context.
Property hydra.member has value of http://www.w3.org/ns/hydra/core#member,
hydra.Collection has value of http://www.w3.org/ns/hydra/core#Collection
and hydra itself has the base Hydra URL of http://www.w3.org/ns/hydra/core# (and so on).

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[lanthaler]

Where are we with this? I'm fine with the current version in this PR or the one Pavlik had before that used absolute URLs everywhere without using the hydra prefix. Both of them explicitly express the intent. I find the original version that maps the absolute URL to itself very confusing. Karol, do you have another idea or are you fine with one of the two options?

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[alien-mcl]

I can live with both. I just understand what's going on with the former - the latter seems a bit more magical. Still, it's not worth of deliberating - there are bigger things ahead.

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[lanthaler]

The latter is trivial as well once you know how JSON-LD processes contexts. It first evaluates the first array entry in @context (the first local context). This defines the hydra prefix plus a few properties. The outcome of this becomes the JSON-LD processor's first "active context". As soon as the processor encounters another context, it updates the active context. This happens with the second context which in this case only consists of "hydra": null. So the JSON-LD processor simply gets rid of the hydra prefix. The resulting active context is exactly the same as the first but without hydra.

Pavlik if you are fine with the current version in this PR I'll go ahead and merge it. If you prefer the other version, please revert the latest change and I'll merge that one instead.

Thanks to both of you!

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[elf-pavlik]

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable