Skip to content
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

Keep original Quads #9

Open
bergos opened this issue Nov 30, 2018 · 3 comments
Open

Keep original Quads #9

bergos opened this issue Nov 30, 2018 · 3 comments

Comments

@bergos
Copy link
Member

bergos commented Nov 30, 2018

Quads may have implementation specific properties, as defined in the Representation spec. These could be line numbers, DOM nodes, etc.. These properties should be kept in the Dataset. The easiest way would be to keep the original Quads, added to the Dataset.

@vhf
Copy link
Member

vhf commented Dec 7, 2018

We could say that quads retrieved from a dataset must be the same objects that were put in the dataset, what do you think? It's a bit different than saying that it preserves properties because you could preserve properties while still returning a different object (same content but other reference).

To illustrate the goal:

const subject = rdf.namedNode('http://example.org/subject')
const predicate = rdf.namedNode('http://example.org/predicate')
const object = rdf.namedNode('http://example.org/object')
const quad = rdf.quad(subject, predicate, object)
const dataset = new Dataset([quad])

const [retrievedQuad] = dataset.match(rdf.namedNode('http://example.org/subject'), null, null, null).toArray()
Object.is(quad, retrievedQuad) // true

It may also be useful to mention that this implies that even if a dataset can be serialized, a serialized dataset cannot be deserialized.

@blake-regalia
Copy link
Contributor

I think that would be up to a specific implementation of dataset and not a broad requirement of all implementations. Indeed, there is great utility in an implementation that does some sort of behind-the-scenes compression of RDF data (and allowing the input objects to go to GC) to allow for more quads than could otherwise be stored in memory -- we wouldn't want to exclude such an implementation from extending the dataset interface, right?

@bergos
Copy link
Member Author

bergos commented Dec 31, 2018

Yes, maybe we let the implementation decide, but I think it's worth to mention in the spec, that implementations may handle it different ways.

Also I think both features are possible in the same implementation. If it's one data factory, which implements the Data Model + Dataset, the Term objects could just store the index to the actual value and implement the value property with a getter.

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

No branches or pull requests

3 participants