Skip to content

Relationship to the RDF/JS Dataset interface(s) #166

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

Open
iherman opened this issue Oct 10, 2019 · 2 comments
Open

Relationship to the RDF/JS Dataset interface(s) #166

iherman opened this issue Oct 10, 2019 · 2 comments
Labels
defer-future-version Defer this issue until a future version of JSON-LD

Comments

@iherman
Copy link
Member

iherman commented Oct 10, 2019

This may be way too late... however. I wonder whether it is possible to bring the types defined in 9.2 RDF Dataset Interfaces to the interfaces defined in the RDF/JS: Dataset specification 1.0 and RDF/JS: Data model specification, as worked on by the RDF JavaScript Libraries Community Group. After all our interfaces are very close to the CG's interfaces, although the latter might be a bit convoluted (in RDF/JS a Quad consists of three Term-s, as opposed to strings, Term has its own interface).

This may lead to a backward compatibility issue (I do not know) and may force to change the implementations a bit. But getting closer to a Javascript community is useful.

@rubensworks, I believe you are active in that CG (or at least your colleagues are), any feeling about this?

Again, it may be too late, but acknowledging this relationship in the document, hinting at a possible alignment in future versions may be useful.

@rubensworks
Copy link
Member

Unfortunately the JSON-LD API Dataset and RDFJS Dataset interfaces are quite different for two reasons:

  1. JSON-LD API Dataset separates graphs by graph name, while RDFJS Dataset places everything in one datastructure as quads.
  2. The triple/quad are indeed quite different. RDFJS chose for Term datastructures, while JSON-LD API uses raw strings. Additionally, RDFJS incorporates graph names at this level, while JSON-LD API only considers triples at this level.

While it may be useful to align with RDFJS in JavaScript implementations, it may not be necessary for other languages to adopt these datastructures as well.

However, I think it is at least possible to implement both the JSON-LD API and RDFJS interfaces at triple/quad level in JavaScript implementations, as this is already mostly achieved by the current jsonld.js implementation.

So yes, I agree that it's useful to acknowledge the link in the document, and suggest alignment with both interfaces (assuming JS implementations), but I'm not sure about forcing it at this stage.

@iherman
Copy link
Member Author

iherman commented Oct 11, 2019

This issue was discussed in a meeting.

  • RESOLVED: Defer RDFJS integration to a future version, and work with the CG to ensure consistency
View the transcript Relationship with RDF/JS dataset
Rob Sanderson: #166
Rob Sanderson: Let’s do this one first because I hope it will be equally quick then we’ll do that.
Ivan Herman: It’s a little bit like the previous thing. It’s probably way too late to touch this, it’s a bit unfortunate that this is the case, I’m playing with something that’s using the RDF output of the jsonld parser in JavaScript. While I realized there is another API by the CG out there but I have to convert what I get from json-ld to that and it’s unfortunate, but it’s just too late.
… I think this is something we should put into the same bin as postponing … and there may be backwards compatibility issues and it’s not that simple to handle it.
Gregg Kellogg: I think perhaps we should lobby RDF/JS to include some additional interfaces to do it. We basically invented interfaces for datasets to support the needs of the algorithm to iterate over graphs and triples within that graph, the RDF/JS only allows iterating over quads.
… If there was a way to add something to create a subset of a dataset that just represented just the quads for a graph then we could use that and it would be great.
… Then we could align with these things, but given our need to separate the triples from the graph and that’s true for pretty much everything else, TriG for instance, it seems like it would be really useful for that interface to provide for that.
… If they had that we could use it, otherwise we just have to defer.
Dave Longley: +1 to gregg
Rob Sanderson: Given it’s a CG spec we can’t normatively refer to it.
… I’m also in favor of deferring.
Ivan Herman: And keeping it open.
Proposed resolution: Defer RDFJS integration to a future version, and work with the CG to ensure consistency (Rob Sanderson)
Gregg Kellogg: +1
Ivan Herman: +1
Rob Sanderson: +1
Dave Longley: +1
Pierre-Antoine Champin: +1
Benjamin Young: +1
Resolution #3: Defer RDFJS integration to a future version, and work with the CG to ensure consistency
Dave Longley: As an author of the JS implementation we’ve tried to get alignment as much as possible up to this point.
… With RDF/JS’s APIs.

@iherman iherman added the defer-future-version Defer this issue until a future version of JSON-LD label Oct 11, 2019
@pchampin pchampin moved this to Future Work in JSON-LD Management May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defer-future-version Defer this issue until a future version of JSON-LD
Projects
Status: Future Work
Development

No branches or pull requests

2 participants