blank nodes - SPARQL: Selecting the nth blanknode -


take following graph:

:foo :p _:b0 ;    :p _:b1 ;    :p _:b2 .  _:b0 :p1 :apple ;    :p2 :banana .  _:b1 :p3 :cantaloupe ;    :p4 :date ;    :p5 :elderberry .  _:b2 :p6 :fig . 

notice: :foo subject of 3 triples same predicate, :p. each of triples has blanknode object.


is possible write sparql query selects triples _:b1 subject?


edit: before proposing answer, please understand looking clever solution question, in sparql. assume triple store fixed (ie: nothing can done change data). graph show above contrived; each blanknode not have same number of p/o triples. if each had 1 triple however, following sparql query might suffice:

select ?b1 {    :foo :p ?bn .    ?bn ?p ?o } limit 1 offset 1 

obviously, concern here returning same blanknode each time. know it's set , inherently unordered, repeatable results ordering not guaranteed; honestly... fixed triple store, sincerely doubt dfa return different blanknode ordering between queries. clever ideas?

you can't select 'nth' blank node in sparql, 2 reasons:

  1. an rdf model set: triples unordered.
  2. a blank node represents resource without identifier - means can't (directly) addressed/identified.

in rdf/sparql work blank nodes in indirect fashion: instead of trying address them directly (which, saw above impossible definition of blank node has no identifier), @ things connects them other resources, is, statements in involved. after all, statements give blank node contextual meaning.

in case: differences between _:b1 , other 2 blank nodes in statements in play role of subject. query in sparql triples _:b1 subject, should @ data , see that, _:b1 uniquely has property :p3 value :cantaloupe. query so:

   construct { ?s ?p ?o }    { :foo :p ?s .            ?s :p3 :cantaloupe ;               ?p ?o .    } 

on side note: several sparql engine implementations offer functionality work around problem of blank nodes having no (global) identifier. in many cases, introduce non-standard syntax extension or custom function allows directly address blank node in sparql query. want stress that non-standard, unlikely work across different endpoints, , therefore best avoided.

if find can't work without somehow addressing blank nodes directly, should consider not using blank nodes @ in data, creating proper iris these things instead.

update update question asks this: "can make use of undocumented feature in unnamed specific implementation of sparql query is, strictly speaking, not legal, or not guaranteed give result want, , away it?" answer question is: yes, depends on sparql implementation you're using, , it's very bad idea, reasons i've given above.

many (most?) triplestores indeed give same result in same order between queries in practice, though that not guaranteed (i can't stress enough) , shouldn't rely on it. of course, can ordered query result using order by clause on query, won't in case since relative ordering of blank nodes undefined in sparql (so query engine free return _:b1 , _:b2 in order sees fit, if there order by clause). worse: while input rdf file may contain blank node identifiers _:b1 , _:b2, not sparql query give back. many triplestores substitute blank node identifiers internally generated ids, , sparql query return _:genid-908c909aeacc4b6da3d3059e18706d68-b1 instead of _:b1.

and if blank node id reliably somehow: gonna it? blank node blank. id carries internal book-keeping purposes - can't use blank node query further.

trust me: it's bad idea. if can't change data, rely on properties connect blank nodes , query those.


Comments

Popular posts from this blog

html - Outlook 2010 Anchor (url/address/link) -

javascript - Why does running this loop 9 times take 100x longer than running it 8 times? -

Getting gateway time-out Rails app with Nginx + Puma running on Digital Ocean -