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

Term normalization for .quad function? #145

Open
blake-regalia opened this issue Jan 23, 2019 · 1 comment
Open

Term normalization for .quad function? #145

blake-regalia opened this issue Jan 23, 2019 · 1 comment

Comments

@blake-regalia
Copy link
Contributor

blake-regalia commented Jan 23, 2019

While this issue is related to the .equals function, it actually exists outside the scope of the other discussions we've had. This one might be addressed by amending the definition of the .quad function itself, but right now there is asymmetry in the naive implementation:

let realTerm = factory.namedNode('http://ex.org/red');
let fakeTerm = {
	termType: 'NamedNode',
	value: 'http://ex.org/red',
};

let realQuad = factory.quad(realTerm, realTerm, realTerm, realTerm);
let fakeQuad = factory.quad(fakeTerm, fakeTerm, fakeTerm, fakeTerm);

realQuad.equals(fakeQuad);  // `true`
fakeQuad.equals(realQuad);  // throws exception

Most importantly, without specifying some needs for normalizing arguments passed to .quad (as it is now), we will see different behavior, i.e., inconsistencies in the results of .equals, between implementations that normalize terms passed to .quad and those that don't.

I understand that the parameter type is specified as Term to the .quad function, but I think it's important to at least consider and discuss these circumstances. Possibly related to #104 and #137

@RubenVerborgh
Copy link
Member

RubenVerborgh commented Jan 23, 2019

We shouldn't overthink. .quad expects Term instances. If passed something else, behavior is undefined. Normalization through #137.

I don't want to discourage good discussions, do keep coming up with corner cases. However, many issues are full of "fake Term" corner cases, whereas I yet have to see the first such fake object in the wild. There is no good reason to create them—not even in transit, because we have the RDF syntaxes for that.

Suggestion: let's assume that fake Term instances won't be a thing. I think it's prudent to guard for undefined or null (which I have seen in the wild), but I happily give up on these if that means that other non-instances are no longer considered either, for simplicity's sake.

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