GH-5573: support to refine the @context of a JSON-LD document

[aschwarte10]

This change introduces a new setting for the JSONLDWriter, that allows to configure a JSONLDContextProvider.

GitHub issue resolved: #5573

With such JSONLDContextProvider it is possible to refine the JSON-LD @context in an application.

Example:

{
    "@id": "https://example.com/bob",
    "@type": "Person",
    "label": {
        "en": "Bob"
    },
    "name": "Bob",
    "@context": {
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "foaf": "http://xmlns.com/foaf/0.1/",
        "@vocab": "https://example.com/",
        "label": {
            "@id": "rdfs:label",
            "@container": "@language"
        },
        "name": "foaf:name",
        "Person": "foaf:Person"
    }
}

---

PR Author Checklist (see the contributor guidelines for more details):

• my pull request is self-contained
• I've added tests for the changes I made
• I've applied code formatting (you can use mvn process-resources to format from the command line)
• I've squashed my commits where necessary
• every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

[aschwarte10]

@hmottestad the build failure I had to fix manually locally as well

Error:  The build could not read 1 project -> [Help 1]
Error:    
Error:    The project org.eclipse.rdf4j:rdf4j-server-boot:5.2.1-SNAPSHOT (/home/runner/work/rdf4j/rdf4j/tools/server-boot/pom.xml) has 1 error
Error:      Non-resolvable parent POM for org.eclipse.rdf4j:rdf4j-server-boot:5.2.1-SNAPSHOT: The following artifacts could not be resolved: org.eclipse.rdf4j:rdf4j-tools:pom:5.2.1-SNAPSHOT (absent): Could not find artifact org.eclipse.rdf4j:rdf4j-tools:pom:5.2.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 4, column 10 -> [Help 2]
Error:  

One of the .pom files referecnes a 5.2.1 snapshot

[hmottestad]

Is this a feature of any other json-ld implementations? Would framing provide you with a feasible solution instead?

[kenwenzel]

I'm not against using this specific extension but I also wonder if framing would be the better approach in this case.

[aschwarte10]

Thanks @hmottestad and @kenwenzel for the feedback and the valid question why not solve it with framing.

The use of @context refinements was an explicit design decision (over framing) in our application. Unfortunately, I was personally on vacation during the design phase and cannot replicate the full reason for that decision.

In the end, it is about self-contained RDF documents, where no additional frame information is required to get it back to RDF. What we want to achieve is not really changing the structure, but going a step further with abbreviation for some simple properties, i.e. "rdfs:label" shows up as "label". This means: for specific IRIs we want to have shorter representation in our resulting document.

Does this sound reasonable?

Meanwhile, I will clarify further with my colleagues to get more details.

[hmottestad]

The compact algorithm is allowed to be used with your own context, so it's a valid use case. The way we've done it with framing is that we allow users to provide their own document directly, would it be a good solution if we allow you to completely override the context document?

Overriding the document fully would allow us to support that feature without users writing code, for instance if we want to support it in the workbench or if we want to allow users to set it when using the console.

[aschwarte10]

would it be a good solution if we allow you to completely override the context document?

You mean something like

mpJsonLd.set(JSONLDSettings.CONTEXT, "{ ... ful context here ... }")

(Similar to how it is done in org.eclipse.rdf4j.rio.jsonld.JSONLDWriterTest.testFraming()

Sure, this is also fine for use. We just want control over the context.

Great feedback (looking at consistency 👍

@hmottestad can you confirm that the above is what you mean? Then I can update the PR by beginning of next week. Thanks

[hmottestad]

would it be a good solution if we allow you to completely override the context document?

You mean something like

mpJsonLd.set(JSONLDSettings.CONTEXT, "{ ... ful context here ... }")

(Similar to how it is done in org.eclipse.rdf4j.rio.jsonld.JSONLDWriterTest.testFraming()

Sure, this is also fine for use. We just want control over the context.

Great feedback (looking at consistency 👍

@hmottestad can you confirm that the above is what you mean? Then I can update the PR by beginning of next week. Thanks

Yes, exactly like we do with framing.

We already have FRAME and EXPAND_CONTEXT, the name for the context used during compaction is just context so JSONLDSettings.CONTEXT is a good choice.

We should probably check that the user doesn't use JSONLDSettings.CONTEXT when framing or expanding.