-
Notifications
You must be signed in to change notification settings - Fork 156
Losing Last Element in RDF List #530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is that the right issue id? |
Whoops! A little number dyslexia. Corrected. |
I found the point in the [ {
"@id" : "http://example.com",
"http://example.com/property" : [ {
"@id" : "urn:a"
} ]
}, {
"@id" : "urn:a",
"@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
"@value" : "a"
} ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
"@id" : "urn:b"
} ]
}, {
"@id" : "urn:b",
"@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
"@value" : "b"
} ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
"@list" : [ {
"@value" : "c"
} ]
} ],
}, {
"@id" : "urn:c",
"@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
"@value" : "c"
} ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
"@list" : [ ]
} ]
} ] However, as far as I understood, the last element of an {
"@id" : "urn:c",
"@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
"@value" : "c"
} ],
"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
"@id" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"
} ]
} |
List representation is shortcut in JSON-LD using <http://example.org/a> <http://example.org/b> (("c" "d" "e")) . We can see the following: {
"@context": {
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
},
"@graph": [
{
"@id": "_:g70196264024700",
"rdf:first": "c",
"rdf:rest": {"@list": ["d", "e" ]}
},
{
"@id": "http://example.org/a",
"http://example.org/b": {
"@list": [{"@id": "_:g70196264024700"}]
}
}
]
} JSON-LD does not preserve blank node identifiers, and in general RDF does not preserve them. The fact that jsonld-java may preserve blank node identifiers in some cases, allowing them to be updated, as a non-standard feature. As you note, skolemization can be used to do this, but then you have something that is not really an RDF List (until de-skolemized). Because an empty list ( You can certainly write a list using standard JSON-LD syntax for Trying to use JSON-LD as a patch format for modifying graphs containing lists is out of scope, and cannot be standardized. It can be used manipulate an RDF graph transformed into the JSON-LD domain and manipulated, say, using JavaScript, but this essentially creates a new graph. There are patch formats, such as SPARQL Update or LD Patch which may be more suitable for your use case. Regarding the issue #277, resolved in 2013, that ship has sailed. If there was strong interest, we could consider adding an API option, similar to the |
We have web application that needs to be able to modify RDF lists from a triple store and propagate the changes back. To do this, we are utilizing jsonld-java to serialize the RDF into JSON-LD, modifying it in the web app, and then sending it back to be deserialized and stored in the triple store. Originally, we were using blank nodes like the ones shown in Turtle below.
However, we discovered that blank node lists are collapsed during serialization thus losing all the blank node IDs.
With blank node IDs removed, we are no longer able to reference the existing RDF in the triple store to perform updates when the lists are modified in the web-app without much more complex logic. To avoid this, we skolemized the blank node IDs into IRIs.
However, when serializing the skolemized triples, the IRI for the last element in the RDF list is hidden, in this case
urn:c
. This leads to the same problem we were having when using blank node IDs.Issue #277 seems to be the point where the implementation changed from serializing lists in the manner we expect to this new compact way. Is there any way we can get around this so that the last blank node of a list is not collapsed?
The text was updated successfully, but these errors were encountered: