rdfjs/public

elf Pavlik

@elf-pavlik

only difference seems with how one would use that 'object of the interfaces'

factory.namedNode('https://foo.example') vs new rdfjs.NamedNode('https://foo.example')

victor felder

@vhf

(you could even const {namedNode} = require('@rdfjs/data-model') and not use the factory object)

Austin Wright

@awwright

@elf-pavlik Well typically if you call a constructor as a function it returns a new instance of itself; String("foo") is functionally the same as new String("foo")

victor felder

@vhf

Looking at https://www.w3.org/TR/IndexedDB-2/#factory-interface , the fundamental difference is that IndexedDB is supposed to be implemented by browsers (it's a browser API, not a JS one), that's why it's accessible on window. I might be missing your point though

Austin Wright

@awwright

Though personally, I prefer the new form because it's more transparent to the developer about what's going on (it's probably going to generate a new instance of that interface)

victor felder

@vhf

Note that new String('foo') and String('foo') are different

elf Pavlik

@elf-pavlik

store.match(null, null, new NamedNode('https://foo.example/bar'))
vs
store.match(null, null, namedNode('https://foo.example/bar'))

victor felder

@vhf

> new String("foo")
[String: 'foo']
> String('foo')
'foo'
> String('foo') === String('foo')
true
> new String('foo') === new String('foo')
false
> String("foo") === 'foo'
true
> new String("foo") === 'foo'
false

Austin Wright

@awwright

I see

elf Pavlik

@elf-pavlik

actually I find that new inconvenient if one created instance somewhere else than when declaring variable

Austin Wright

@awwright

I've actually implemented IndexedDB on Node.js and submitted implementation feedback, Since then IndexedDB 2 was released; but note that the factory is producing objects anchored to some origin; the same way document.createElement() creates elements anchored to some document

Also it's a bit more careful in how it defines the interface; note it's using partial interface

elf Pavlik

@elf-pavlik

I haven't dive too deep in WebIDL but possibly we might want to use partial interface since we expect implementations to extend them

@awwright maybe you can suggest fix for ReSpec error visible on top right in https://rdf.js.org/stream-spec/

Failed to parse WebIDL: Syntax error at line 7, since interface Store: Store implements Source; ^ Unrecognised tokens.

I think implements got deprecated in WebIDL

Austin Wright

@awwright

@elf-pavlik Yeah, I'm no expert but I'd be happy to look into it

victor felder

@vhf

We might also want to use [NewObject] https://www.w3.org/TR/WebIDL-1/#NewObject

elf Pavlik

@elf-pavlik

but I don't think we can define Sink and Source as mixin since they have direct implementations

I agree that WebIDL definitions may need some polishing, if you have specific suggestions I think PR would work best to get them in

Eric Prud'hommeaux

@ericprud

@bergos, i see your name on the rdfjs/dataset-spec@85d6e3b commit to the dataset spec.

Eric Prud'hommeaux

@ericprud

was the intention that?:

Both this and the argument are mutable datasets.
Both this and the argument will have blank node labels rewritten per RDF Dataset Normalization. These changes will result in datasets that are graph isomorphic to the originals.
Apart from blank node rewriting, no other changes, e.g. .add() or .delete(), will occur in these datasets.

Eric Prud'hommeaux

@ericprud

One commitment I'm looking for is whether a caller can count on .equals() performing normalization. .toCanonical() appears not to canonicalize the supplied graph, merely supply a string representation of a canonicalized copy of it.

victor felder

@vhf

The intention is that the argument should be treated as an immutable dataset. It would be impractical to require implementations to enforce this, hence these notes: https://rdf.js.org/dataset-spec/#dom-dataset-equals

I think this discussion is relevant to your question: rdfjs/dataset-spec#23

victor felder

@vhf

That part of the spec is still WIP, any input is welcome on this. My implementation of equals compares the toCanonical version of both but this might change. toCanonical doesn't canonicalize the graph, that's correct, similar to toString

Eric Prud'hommeaux

@ericprud

so in your implementation, there's no apparent rewriting of bnode labels in either this or the argument?

victor felder

@vhf

I think toCanonical does rewrite bnodes, it uses https://github.com/digitalbazaar/rdf-canonize under the hood

Eric Prud'hommeaux

@ericprud

If rdf-canonize() makes a new canonical copy of the original, calling .toCanonical() won't modify the argument; so that argument can be thought of as immutable.

victor felder

@vhf

Yes, that argument should be thought of as immutable. This is why we added these notes making implementers aware that they should think of the argument as immutable.

Eric Prud'hommeaux

@ericprud

but the .equals() text sort of overrides that by suggesting bnode rewrite

i'm trying to figure out the details of the current plan for .equals(), to the extent those details have been considered.

victor felder

@vhf

I see your point now, I agree it could be made clearer. This: Blank Nodes will be normalized. should be taken as Copies of this and the argument will be compared after blank nodes normalization, the normalization shouldn't be applied to the originals, they shouldn't be modified.

Let's try to make the final version better than the WIP once we agree on what exactly .equals should compare

Eric Prud'hommeaux

@ericprud

sounds good. i weighed in on that as well. tx for the pointer

Austin Wright

@awwright

Why does RDF Dataset Normalization apply to us? Two bnodes can have the same label and still be different bnodes.

Or more specifically, bnode labels are a property of the media type, if any are defined at all. [ ] is an example of an unlabeled bnode in Turtle. The label doesn't exist in RDF proper, and since RDFjs isn't a serialization, I'm not sure it makes sense to have process-wide bnode labels.

Eric Prud'hommeaux

@ericprud

The RDF spec documents how the outside world should interact with RDF graphs. The practical programmer interface can be much more intimate.

Eric Prud'hommeaux

@ericprud

I believe that not having bnodes in the process would mean you can't use bnodes. If you get a quad with a bnode back from getQuads(), you expect to be able to identify that bnode in subsequent getQuads(), removeMatching(), addAll(), etc

otherwise, getting a bnode back would basically be a dead end.

Austin Wright

@awwright

New version of "rdf" out with Dataset, Quad, factory, Graph#simplyEntails, TermMap, PrefixMap, and several improvements: https://yarnpkg.com/en/package/rdf

Please test and submit feedback :)

elf Pavlik

@elf-pavlik

:clap: :clap: :clap:

Angelo Veltens

@angelo-v

Hi, I am trying to use fetch-lite in a browser environment. What I got from the readme it is meant to work there.
Unfortunately I am getting an error, because the finished imported here from readable-stream is undefined.

finished is somehow not exported in the browsers version, see https://github.com/nodejs/readable-stream/blob/master/readable-browser.js

cc @bergos

Tomasz Pluskiewicz

@tpluscode

would be nice if you could share a stackblitz or smth which reproduces the problem

readable-stream is yet another package? how are you serving your code? webpack?

Angelo Veltens

@angelo-v

yep tested with webpack dev server so far, I could prepare an example, just wanted to be sure that this is nothing obvious

Tomasz Pluskiewicz

@tpluscode

have not had this myself and I've used those packages in web projects

Where communities thrive

People

Repo info

Activity