Change defaultGraph iri

[joepio]

trafficstars

// in data-factory-internal.ts
export const defaultGraphURI = 'chrome:theSession'

In Firefox:

new URL("chrome:thesession")
// TypeError: chrome:thesession is not a valid URL.
new URL("anyOtherRandomScheme:anyvalue")
// URL {..valid}

This probably has to do with security considerations in Firefox, since they mention it in the tabs.create docs.

Creating URL objects from NamedNode (including DefaultGraph) values is quite common.

~~Should we change the defaultGraphURI to an empty string? This seems most appropriate, since this is what the RDFJS Taskforce spec uses.~~ Edit: empty strings also create invalid URLs.

[dmitrizagidulin]

+1, I too think we should change the defaultGraphURI to an empty string.

[rescribet]

chrome:theSession is a named graph (so NamedNode). It is used as the default named graph (NamedNode), not to be confused with the RDF default graph (DefaultGraph).

Should we change the defaultGraphURI to an empty string

An empty string isn't a valid IRI, so that would cause a lot of problems. E.g. the trivial implementation of Creating URL objects from NamedNode (including DefaultGraph) values is quite common. would throw a TypeError.

We have used rdf:defaultGraph before, which is a valid url and parses in firefox as well. Though no registered scheme rdf exists. Though I think it has logical behaviour in practice;

• Keeps the API and downstream code simple (e.g. code only has to expect named or blank nodes)
• Calling putBack will still fail as intended (since it isn't a document but a concept).
• Taskforce adhering projects should still work (factory.defaultGraph().equals(quad.graph) === true).

[joepio]

How about rdfjs:defaultGraph instead of rdf? Seems to make sense, since defaultGraph is not in the rdf spec, and it refers to something created in RDFjs.

[joepio]

Just discussed this with @megoth and @timbl.

Even better than using rdfjs:defaultGraph is to use rdfjs:defaultGraph-${generateUUID()}, so for every initialized store we'd have a unique value. However, this means that we'd need to persist this value in the store (IndexedFormula), and that would mean that the Statement constructor (which calls defaultGraph() needs to know about the Store instance. Not sure on how this should behave.

[TallTed]

Using unregistered URI schemes is poor form, not only but significantly because validly used ad-hoc namespace definitions may over-run both the suggested rdf: and rdfjs:.

If there is legitimate need here for such rdf: and rdfjs: scheme URIs, it stands to reason there would be legitimate need elsewhere, and thus requisite steps should be taken to register and specify these schemes -- even if they're largely handwaves -- and I would suggest that the structure here become rdfjs:rdflib:defaultGraph-${generateUUID()}.

Perhaps better, please consider registering the rdflib: scheme and using rdflib:defaultGraph-${generateUUID()}.

[elf-pavlik]

http://rdf.js.org/data-model-spec/#defaultgraph-interface

value contains an empty string as constant value.

Instance of RDFJS DefaultGraph has empty string as its value

chrome:theSession is a named graph (so NamedNode). It is used as the default named graph (NamedNode), not to be confused with the RDF default graph (DefaultGraph).

This default named graph seems like some rdflib.js internal implementation detail. I also don't understand why rdflib.js doesn't just use an instance of DefaultGraph.

[rescribet]

I also don't understand why rdflib.js doesn't just use an instance of DefaultGraph

All downstream code will have to account for an additional termType, client code, parsers, serializers will all need to know this. Even using undefined would be easier (esp. with optional chaining). Why make software less simple than it has to be?

implementation detail

The end-user doesn't need to know this, since factory.defaultGraph().equals(quad.graph) === true. Using that method rather than checking for some specific termType value directly makes minimal assumptions and will also allow to re-use the code for when a named graph is used.

[elf-pavlik]

factory.defaultGraph().equals(quad.graph) === true

I think I still misunderstood something. factory.defaultGraph() will never return true from equals() if compared to any instance of NamedGraph

It also 'under the hood' will check termType anyways.

http://rdf.js.org/data-model-spec/#datafactory-interface

defaultGraph() returns an instance of DefaultGraph

http://rdf.js.org/data-model-spec/#defaultgraph-interface

termType contains the constant "DefaultGraph" value contains an empty string as constant value. equals() returns true if all general Term.equals conditions hold; otherwise, it returns false.

http://rdf.js.org/data-model-spec/#term-interface

equals() returns true when called with parameter other on an object term if all of the conditions below hold:

• other is neither null nor undefined;
• term.termType is the same string as other.termType;
• other follows the additional constraints of the specific Term interface implemented by term (e.g., NamedNode, Literal, …);

otherwise, it returns false.

BTW equals() always returns a boolean so factory.defaultGraph().equals(quad.graph) looks sufficient without additional === true

[melvincarvalho]

I've been using chrome:theSession to store data that is in the user agent against, for a given session

See:

Tim Berners-Lee @timbl May 14 2018 17:48 It is used for things in the browser. May not be in the IETF. Like chrome://extension/tabulator/src/images/foo.png or words to that effect The logic was “information which the bowser itself has learned in this session, not loaded from a specific resource"

Given that it's not a valid URI it's probably a good idea to change it

rdfjs:defaultGraph-${generateUUID()}

Seems a useful thing to do for the case that you are using rdfjs as your library.

I wonder if there's a generalization to be made here:

Use cases

• Storing data in the user agent for a given session
• Storing data in the user agent for a given origin
• Storing data in the user agent for a given document

The chrome: scheme seems to be out. The http scheme wont work as the browser typically does not allow dereferencing at http visibility level. The URN scheme could work with the right sub scheme (thanks to @kidehen for this suggestion). But this data can indeed be deferenced within a user agent sandbox. So perhaps a new scheme is best after all.

Proposal browser: URI scheme

browser is a colloquial and well understood term for a user agent. It has connotations of user agent specific data

so we could translate

http://origin -> browser://origin

http://document -> browser://document

Maybe also:

localStorage -> browser://localStorage

indexeddb -> browser://indexeddb

etc.

Further work could be to ad ?fingerprint= as a UUID for each browser so that you can use a Pod to sync up devices

seeAlso

@jeff-zucker has done some work putting rdf in localStorage with : https://github.com/jeff-zucker/solid-rest/tree/browserFS and it might be possible to compare notes