-
Notifications
You must be signed in to change notification settings - Fork 152
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
JSON-LD 1.0 @graph syntax #106
Comments
Need to outline a graph including graph example, and describe framing approaches. |
RESOLVED: Adopt the 6 points in ISSUE-106 along with Gregg and Longley's proposal for |
Just to clarify proposed @graph semantics: If @graph references an IRI or subject reference, the semantics are that the statements made by the referenced document are to be considered in the named graph specified by the source document. A processor does not dereference the document to do this, it is left to the application. Source document:
Target document:
The target document is defined by the source document to be in the graph named with ws:BerlinFact. |
The issue of named graphs containing other named graphs can be illustrated by the following document:
This has a default graph referencing a named graph, which in turn references another named graph. The idea would be that graph names all exist in the default graph, so this document would be semantically equivalent to the following:
That is, in the default graph, two objects ("ws:Assertions" and "ws:BerlinFact"), that each have some properties and name graphs containing other information. Note that "ws:BerlinFact" is a subject both to name a graph, and to express properties in another named graph. This can be demonstrated by looking at the results of converting the first document to TriG:
The flattening algorithm would (eventually) be updated to take this into consideration. Note that the process of converting the first to RDF and back again would also result in the second. |
We need to determine what the JSON-LD 1.0 @graph syntax supports. At the moment, I think the current direction is to support the following:
We also need to figure out how @graph is treated when compacting, expanding and framing - but I believe those decisions probably will not affect the syntax. Anything else that should be considered regarding @graph syntax?
The text was updated successfully, but these errors were encountered: