Can't single column result SPARQL queries be used as node selectors?

[DaniFdezAlvarez]

I think that was in the spec at some point, but the current spec seems to define a node selector as one of an RDF node or a triple pattern.

I think that was a really poweful feature to link a shape with custom node groupings.

[ericprud]

The challenge is that we'd like the power of SPARQL without the requirement of SPARQL. Two or three implementations support a keyword-switched extension language, e.g.

SPARQL '''SELECT ?item ?itemLabel WHERE {
  ?item wdt:P279* wd:Q12078 .
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en"
  }
} LIMIT 10'''@START

This could be defined by expanding nodeSpec to take a PREFIX (using PREFIX as a reasonable terminal for the identifier) and a string:

[3 ]	nodeSpec	::=	objectTerm \	triplePattern \	\ string

This kinda skips the question of governance of the extension namespace. We could have a registry, but then folks have to register to avoid collision. Another approach is to say that it's a URL relative to some registry, which would enable unregistered extensions a la:

http://example.org/shapeMapExt123 'something magic here'@START

The delimiter here would be first whitespace (normal lexing rules), but we could tweak it (not backward-compatible) to have '<' '>' delimiters around the URL, though I guess the URL grammar prohibits ' ' just as '>'.

[DaniFdezAlvarez]

Hmm I'm not sure whether adding the requirement of SPARQL seems problematic from a strategical/feature point of view, or from the point of view of maintaining a simple grammar.

Talking purely about features, enabling extensions sounds nice to me, but maybe not as urgent as merely enabling SPARQL. I mean, once you can write actual SPARQL queries you've got all the flexibility one may need to associate any group of nodes with a shape label, and that's a syntax that will be probably familiar to anyone wanting to write a shape map.

If it's just SPARQL indicated with the SPARQL keyword, as in your example, then those potential conflicts with a registry are gone for the moment. I imagine other extensions could be useful for specific cases too, but I picture them mostly like workarounds to avoid complex queries. But maybe I'm thinking too obtuse here...

[ericprud]

The problem with adding SPARQL to the core spec is that it's a big language. ShapeMaps, and even ShEx, are much lighter-weight. I agree it's a great functionality but I'm pretty sure we want ShapeMaps in code that won't have a SPARQL implementation.