Skip to content
This repository has been archived by the owner on Feb 21, 2022. It is now read-only.

Achieve full compliance with RDF/JS Dataset interface #12

Open
alexkreidler opened this issue Oct 24, 2020 · 3 comments
Open

Achieve full compliance with RDF/JS Dataset interface #12

alexkreidler opened this issue Oct 24, 2020 · 3 comments

Comments

@alexkreidler
Copy link

Currently, rdf-dataset-indexed exposes a similar, but not exactly matching API surface to that of the official RDF/JS Dataset spec.

I've listed the function names below to compare, with those from @types/rdf-dataset-indexed followed by @types/rdf-js:

create
addAll
clone
difference
every
filter
forEach
import
includes
intersection
map
merge
remove
removeMatches
some
toArray
toStream
match

vs

addAll
contains
deleteMatches
difference
equals
every
filter
forEach
import
intersection
map
reduce
some
toArray
toCanonical
toStream
toString
union
match

It appears the vast majority of the functionality is already there, and that it wouldn't be difficult to update the API surface.

I think this would provide a huge benefit to the community, by reducing cognitive overhead, and simplifying libraries that might have to currently use their own wrappers. It would also make it easier for people to get started, as AFAIK there isn't a good standard implementation of the RDF/JS dataset spec.

Of course, this would be a breaking change to the external API, so we'd need a new version.

Let me know what you think and if there's anything I can do to help!

@vhf
Copy link
Contributor

vhf commented Oct 26, 2020

Yes, the current API comes in part from the first dataset description (the one that is/was hosted on a github wiki page) and in part from the dataset spec. I agree with all your points, particularly regarding avoiding confusion and making it easier for people to get started.

What you are asking for is here: #3 but I'm not sure it will ever make it into this package

@bergos
Copy link
Contributor

bergos commented Oct 26, 2020

The spec very clearly states that the Dataset interface is experimental. There were different opinions on how to interpret that part of the spec, which would end up in incompatible implementations. That's why it was tagged experimental. Until that is resolved, the rdf-ext packages will use the older rdf-ext Dataset interface + DatasetCore. From my point of view, this should be fixed in the ts binding definition. If there is no way to tag the interface experimental, it should be removed.

@alexkreidler
Copy link
Author

We are in the process of moving the types to @rdfjs/types or a similar package, and also implementing a more comprehensive review process.

I agree, maybe it would be better to either separate experimental types into a different package or tag them with something like the TSDoc @alpha modifer.

However, I'll leave this open, as I believe the rdf/js community is moving towards stabilizing the Dataset interface itself, and I think it would be great to have implementations standardized to improve interoperability.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants