JSON-LD not compliance with the standard

[sandroacoelho]

Hi @m1ci , @jnehring

Our current JSON-LD produced by FREME Common Module is not fully compliance with the standard. The problems are:

1. Context should be just an URL that represents all ontologies that @graph collection have;

2. NIF and RDF ontologies are not fully mapped in context;

3. Some properties are not mapped in JSONLD-playground (E.g: itsrdf:taConfidence and nif:anchorOf). If it happens, you will lose data when you convert to flattened, compacted, framed or n-quads format ;

We can fix all of points above as follow:

1. Use the service http://jsonld-context.io/ to produce our context directly

{
"@context": "http://www.jsonld-context.io/api/v1?ontology=http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core&ontology=http://www.w3.org/2005/11/its/rdf",
}

OR store / distribute it using a static file under www.freme-project.eu

{
"@context": "http://www.freme-project.eu/context.jsonld",
}

2. The service http://jsonld-context.io/ reads any ontology and produces a complete context. We don't need to care about it

3. All keys in JSON-LD must be produced without prefixes. The context is responsible for assign the respective prefixes on it

E.g

{
	"@context": "http://www.jsonld-context.io/api/v1?ontology=http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core&ontology=http://www.w3.org/2005/11/its/rdf",
	"@graph": [{
		"@id": "b4ac3c64c1ac9b5d3178d2ec3ba101c7",
		"@type": ["Context", "OffsetBasedString"],
		"beginIndex": 0,
		"endIndex": 33,
		"isString": "Diego Maradona is from Argentina."
	}, {
		"@id": "b4a3fc77148b17cd21face1c1169353f",
		"@type": "Annotation",
		"taAnnotatorsRef": "http://freme-project.eu/tools/freme-ner",
		"taClassRef": ["http://dbpedia.org/ontology/Place", "http://dbpedia.org/ontology/Location", "http://dbpedia.org/ontology/PopulatedPlace", "http://nerd.eurecom.fr/ontology#Location", "http://dbpedia.org/ontology/Country"],
		"taConfidence": 0.9804963628413852,
		"taIdentRef": "http://dbpedia.org/resource/Argentina",
		"referenceContext": "b4ac3c64c1ac9b5d3178d2ec3ba101c7"
	}, {
		"@id": "ca6e4dcf014c81a0ced8b01d849a29c9",
		"@type": "Annotation",
		"taAnnotatorsRef": "http://freme-project.eu/tools/freme-ner",
		"taClassRef": ["http://dbpedia.org/ontology/Person", "http://dbpedia.org/ontology/SportsManager", "http://dbpedia.org/ontology/SoccerManager", "http://nerd.eurecom.fr/ontology#Person"],
		"taConfidence": 0.9869992701528016,
		"taIdentRef": "http://dbpedia.org/resource/Diego_Maradona",
		"referenceContext": "b4ac3c64c1ac9b5d3178d2ec3ba101c7",
		"taMsClassRef": ["http://dbpedia.org/ontology/SoccerManager"]
	}]
}

Best,

[m1ci]

Our current JSON-LD produced by FREME Common Module is not fully compliance with the standard. The problems are:

The JSON-LD is generated by Jena. So I would say that it is compatible.

1. Context should be just an URL that represents all ontologies that @graph collection have;

No, contexts can be also provided as part of the document. Not needed to be hosted somewhere and referenced via URI.

1. NIF and RDF ontologies are not fully mapped in context;

OK, but this does not mean that the JSON-LD output is not according to the standard.

1. Some properties are not mapped in JSONLD-playground (E.g: itsrdf:taConfidence and nif:anchorOf). If it happens, you will lose data when you convert to flattened, compacted, framed or n-quads format ;

I don't understand what you mean by "not mapped"? In the context there is
"itsrdf" : "http://www.w3.org/2005/11/its/rdf#",

As for your proposals:

1. Use the service http://jsonld-context.io/ to produce our context directly OR store / distribute it using a static file under www.freme-project.eu

We can use the http://jsonld-context.io service to generate the context and then host it. But I would host it on some more stable place. e.g. at the same location where is hosted the NIF ontology - that is somewhere under persistence.uni-leipzig.org/nlp2rdf/ontologies/

1. All keys in JSON-LD must be produced without prefixes. The context is responsible for assign the respective prefixes on it

Your claim "Keys must be without prefixes" its not true - they can be with prefixes. Its matter of choice. Yes, the context takes care of them.

[jnehring]

I think we should trust the Jena library. Further m1ci discussed that we can leave it as it is.

There is only one thing, about the jsonld-context. What exactly does that mean? Do we need to rely on an external API when we use this context? And what would this change mean for the implementation? Do we need to change the output of each e-Service in case the output format is JSON-LD?

[m1ci]

There is only one thing, about the jsonld-context. What exactly does that mean?

It allows clients to use shortcut terms, like the first name of a mutual friend, to communicate more quickly but without losing accuracy. It's quite practical cause it simplifies the JSON-LD. For more see https://www.w3.org/TR/json-ld/#the-context

Do we need to rely on an external API when we use this context?

No, there is no need to rely on any external API.

And what would this change mean for the implementation?

Instead of using Jena for generating JSON-LD we will use the library of Sandro. @sandroacoelho please confirm.

Do we need to change the output of each e-Service in case the output format is JSON-LD?

No need to change anything in the e-services. The only thing to be changed will be in the "common" library which generates JSON-LD out of given RDF.