-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
Unfortunately the JSON-LD API Dataset and RDFJS Dataset interfaces are quite different for two reasons:
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. |
This issue was discussed in a meeting.
View the transcriptRelationship with RDF/JS datasetRob 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. |
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 threeTerm
-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.
The text was updated successfully, but these errors were encountered: