search

rdf-ext-archive / discussions

This repo is for discussions all over the rdf-ext project
3 stars 2 forks source link

Handling of default graphs #3

Closed bergos closed 8 years ago

bergos commented 8 years ago

Some stores may have a default graph, like the SPARQL store. Methods like .graph or .match require a IRI parameter for the named graph. What value should be used for the default graph? null is already used for any graph. true would allow to check if the value is set and it's not a string or RegExp object. Are there any reasons to not use true? Could it be handled in a different way?

ktk commented 8 years ago

IIRC in Fuseki the graph name is simply default

bergos commented 8 years ago

I'm not happy with a string value, because beside the default graph only IRIs are allowed for named graphs, so strings could be converted just by checking the type.

ktk commented 8 years ago

Ok I get that. true would be fine for me

retog commented 8 years ago

I'd rather use a specifi constant for "any graph" as "null" seems to be the most obvious choice for the unnmaed default graph of a sparql dataset.

bergos commented 8 years ago

null is already used in the triple matcher for any value. That allows function calls like this: graph.match(subject) to fetch all triples for a single subject. null should be used for any value, to use the same logic in all methods. Also the default graph construct is a store specific use case. Therefore a consistent API is from my point of view more important.

retog commented 8 years ago

I'd suggest to define an additional .defaultGraph method and specify what stores without default graph should do (leave method undefined, invoke the callback with null/undefined?). The only entity in the specs around RDF that is similar to what Store models is the SPARQL DataSet which has a default graph, so it seems justified to have a dedicated method for this rather than some hacks like zje proposal of using true.

As for using null as wildcard, I'm not sure is undefined wouldn't be the better choice, as the arguments of .match define filtering restriction, so "undefined" seems to be an intuitive way of saying "no restriction defined", but this if OT for this issue.

bergos commented 8 years ago

Must be defined in the RDFJS Representation Task Force spec.