Nested @embed directive affects processing at a higher level #171
Comments
|
Hi, |
|
I tried the latest snapshot, and got the same results. It seems that it is an issue with how I am using Titanium. I am starting with an N-Triples file, and processing it as follows: private static boolean frame(Path datasetPath, Path framePath) {
try (BufferedReader datasetReader = Files.newBufferedReader(datasetPath);
BufferedReader frameReader = Files.newBufferedReader(framePath)) {
Document rdf = RdfDocument.of(MediaType.N_QUADS, datasetReader);
Document jsonld = JsonDocument.of(JsonLd.fromRdf(rdf).get());
Document jsonldFrame = JsonDocument.of(frameReader);
JsonObject results = JsonLd.frame(jsonld, jsonldFrame).get();
Pretty.createWriter(System.out).writeObject(results);
return true;
} catch (IOException | JsonLdError e) {
return err("Failed to frame dataset using %s: %s", framePath, e);
}
}When I do this I get the bad results described above, even with the latest snapshot. However, it works if I first use private static boolean frame(Path datasetPath, Path framePath) {
try (BufferedReader datasetReader = Files.newBufferedReader(datasetPath);
BufferedReader frameReader = Files.newBufferedReader(framePath)) {
Document jsonld = JsonDocument.of(datasetReader);
Document jsonldFrame = JsonDocument.of(frameReader);
JsonObject results = JsonLd.frame(jsonld, jsonldFrame).get();
Pretty.createWriter(System.out).writeObject(results);
return true;
} catch (IOException | JsonLdError e) {
return err("Failed to frame dataset using %s: %s", framePath, e);
}
}Am I not converting from N-Triples to JSON-LD correctly? |
|
It looks like there is a bug in N-Triples parser or/and in fromRdf implementation. Can you share the N-Triples input file or check if the intermediary result after |
|
Here's a zip with the N-Triples file and the JSON-LD that |
|
That's interesting. Quick workaround, for now, could be to add |
|
I still get the same problematic output even if I manually add the Graph: {
"@graph": [
{
"@id": "http://n2t.net/ark:/39333/ncg/dataset",
"@type": [
"http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"
],
"http://www.w3.org/2000/01/rdf-schema#member": [
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG03755"
},
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG07554"
},
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG11248"
}
]
},
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG03755",
"http://n2t.net/ark:/39333/ncg/vocab#county": [
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG11248"
}
],
"@type": [
"http://n2t.net/ark:/39333/ncg/type#Mountain"
],
"http://www.w3.org/2004/02/skos/core#label": [
{
"@value": "Crawford Mountain"
}
]
},
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG07554",
"http://n2t.net/ark:/39333/ncg/vocab#county": [
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG11248"
}
],
"@type": [
"http://n2t.net/ark:/39333/ncg/type#Community"
],
"http://www.w3.org/2004/02/skos/core#label": [
{
"@value": "Ichley"
}
]
},
{
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG11248",
"@type": [
"http://n2t.net/ark:/39333/ncg/type#County"
],
"http://www.w3.org/2004/02/skos/core#label": [
{
"@value": "Orange County"
}
],
"http://www.w3.org/2004/02/skos/core#note": [
{
"@value": "Not to be confused with Orange County, CA"
}
]
}
]
}Frame: {
"@context": {
"@base": "http://n2t.net/ark:/39333/ncg/place/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"ncv": "http://n2t.net/ark:/39333/ncg/vocab#",
"nct": "http://n2t.net/ark:/39333/ncg/type#",
"skos": "http://www.w3.org/2004/02/skos/core#",
"records": {
"@container": "@set",
"@type": "@id",
"@id": "rdfs:member"
},
"county": {
"@container": "@set",
"@type": "@id",
"@id": "ncv:county"
}
},
"@type": "rdf:Bag",
"records": {
"@id": {},
"county": {
"@embed": "@always",
"@explicit": true,
"skos:label": {}
}
}
}Result: {
"@id": "../dataset",
"@type": "rdf:Bag",
"records": [
{
"@id": "NCG03755",
"@type": "nct:Mountain",
"county": [
{
"@id": "NCG11248",
"@type": "nct:County",
"skos:label": "Orange County"
}
],
"skos:label": "Crawford Mountain"
},
{
"@id": "NCG07554",
"@type": "nct:Community",
"county": [
{
"@id": "NCG11248",
"@type": "nct:County",
"skos:label": "Orange County"
}
],
"skos:label": "Ichley"
},
"NCG11248"
],
"@context": {
"@base": "http://n2t.net/ark:/39333/ncg/place/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"ncv": "http://n2t.net/ark:/39333/ncg/vocab#",
"nct": "http://n2t.net/ark:/39333/ncg/type#",
"skos": "http://www.w3.org/2004/02/skos/core#",
"records": {
"@container": "@set",
"@type": "@id",
"@id": "rdfs:member"
},
"county": {
"@container": "@set",
"@type": "@id",
"@id": "ncv:county"
}
}
} |
|
The missing {
"@id": "http://n2t.net/ark:/39333/ncg/place/NCG11248"
}is the first item in |
|
Ah, I see. That makes sense. Adding |
Describe the bug
When I create a frame with a nested
@embeddirective, it seems to affect the frame processing at a higher level, which differs from the behavior of the framing processor at the JSON-LD Playground.To Reproduce
Take for example the following graph:
And this frame:
(See the above on the playground).
Expected behavior
On the JSON-LD Playground, the above graph and frame produce these results, which are what I would expect:
countynodes are always embedded and respecting the@explicitdirective, but this does not affect therecordslevel.However, using Titanium I get the following results:
Note that the node for Orange County at the
recordslevel is just an@idreference.Additional context
It seems to me that what is happening is that the
recordslevel is being processed with the default"@embed": "@once"directive, but that the embeddings at thecountylevel are being counted as fulfilling that one embedding, so that at therecordslevel Orange County is never embedded.The text was updated successfully, but these errors were encountered: