-
Notifications
You must be signed in to change notification settings - Fork 0
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
Blank Node Scope #4
Comments
This issue was discussed in the 2022-10-12 meetingSubtopic: Blank Node Scope ✪Gregg Kellogg: If every record is a JSON-LD document, it might have its own context. Or it can be provided externally — as an HTTP header, or an API parameter ✪
... Now, regarding the blank nodes scope. We've discussed it for YAML-LD before.
Gregg Kellogg: Tag definitions and blank node names might be independent between documents. For instance, if we're collecting random documents we might have unexpected consequences if the labels or tags overlap. In the streaming applications though, we might want to share labels (for computing differences, etc) but we won't be able to. ✪
Gregg Kellogg: Next steps on NDJSON-LD — Nicholas? ✪
Niklas Lindström: I do not lack anything other than time. I should write the simplest thing imaginable first, probably... Blank nodes: I do not have a strong opinion on this, we're not using blank node identifiers. JSON-LD document can be an RDF dataset and that is an interesting complication. So every line can represent multiple datasets/graphs. ✪
Niklas Lindström: This does not influence blank nodes question though. ✪
Niklas Lindström: In TriG documents, afaik blank node ids are shared throughout the whole document. ✪
Gregg Kellogg: Different use cases might drive conflicting requirements. ✪
Leonard Rosenthol: There is a difference whether we address a homogenuous case (all documents share a context or grammar) vs the case where documents are heteregenuous (potentially unrelated to each other) - but they happen to share one data stream. Do we want to solve both cases? What are we gaining or losing by doing so? ✪
Gregg Kellogg: NDJSON-LD should be an extension of JSON-LD API because YAML-LD calls upon it. Algorithms operate to transform → JSON-LD internal representation. Consequently, we rely upon that. Regarding the purpose of all this: if we pre-suppose an API and one of this API entry points relates to RDF transformation then doing something multi-dataset becomes really challenging. ✪
Gregg Kellogg: Especially when we think we're collecting unrelated and maybe conflicting records. It would simplify the problem if all the records relate to a single dataset. Unless we have compelling use cases which suggest otherwise. ✪
Gregg Kellogg: We might introduce a "meta" record to specify meta parameters. Like Turtle with their `"@Prefix"` parameters in the header. ✪
https://github.com/prefix -> `@prefix` ✪
Niklas Lindström: +1 For "meta-records"; could e.g. set the context initially (corollary: first row of a TSV as columns) ✪
Niklas Lindström: Going to continue the work on NDJSON-LD. ✪
|
In the meeting, we discussed the possibility of some kind of meta-record that could better control blank-node scope. This could be some kind of record with a directive that resets the blank node namespace between records, or records that form a header to the stream document itself that control such behavior for all records.
In which the two records do not share the same blank node, even though the use the same identifier, or:
In which both records share the same blank node. Perhaps something like For JSON-LD, this would only really come into play when generating RDF, or flattening when blank nodes are renamed, and would be difficult to communicate through the API. Similar thoughts about if each document describes its own disjoint dataset, or they are all considered sub-sets of a single dataset. Easiest course would be to say that the stream format is intended for documents that all relate to the same dataset and blank node identifiers are shared across all documents within a stream. |
@gkellogg — I think you intended for |
Yes, something got lost in the original, I’ve updated the comment. |
This format would require a separate definition for the meta record grammar. Can this be a JSON record? Even more, can we have a JSON-LD context to define its meaning?
|
On the call, I think we discussed that blank nodes would be scoped to each individual record, however this would make using this format in a manner similar to N-Quads unable to represent shared blank nodes.
Most serializations scope blank node identifiers to the file. In this reckoning:
could be semantically equivalent to:
Otherwise, there would be no way to state this using independent records.
Proposal: blank node labels are shared across all documents within a stream.
The text was updated successfully, but these errors were encountered: