--named-graph vs FROM different results (prefix not respected in --named-graph CLI param)

Support
1

I’m sure this is something stupid I’ve done but I’m tearing my hair out on this…
I loaded some data:
stardog data add --named-graph repos:fibo FIBO.zip
and got confirmation of 70k triples loaded
If I then do the following I get the results expected:
stardog query execute --named-graph repos:fibo “select * where {?s ?p ?o} limit 10”
If however I use FROM instead of --named-graph I get nothing:
stardog query execute “select * from repos:fibo where {?s ?p ?o} limit 10”
The prefix repos is defined in the database as:
repos=http://com.adaptive.repository/

2

Shouldn’t you use FROM NAMED then?

3

No, FROM is correct since the pattern is in the default scope.

Pete, what’s the output of select distinct ?g { graph ?g { ?s ?p ?o } } or even select ?g (count(*) as ?c) { graph ?g { ?s ?p ?o } } group by ?g?
I suspect some IRI mismatch…

Cheers,
Pavel

4

OK I answered my own question. The problem is that the --named-graph parameter in the CLI does not respect the prefix defined in the database, so that the data was loaded into graph "repos:fibo" not "http://com.adaptive.repository/fibo". If I query using the following I get the results:
select * from <repos:fibo> where {?s ?p ?o}
then I get the results.

Can this problem be considered a bug? Is it not reasonable to expect the prefixes to be honored? This behavior should at least be documented in the man pages for the CLI.
Personally I would like the prefix to be honored: we have shell scripts for various loading tasks and we don't want to have to edit them all if we happen to change how the prefixes are mapped to URIs in the database - the prefixes are a useful level of indirection.

5

Hi Pete,

I agree that it would be useful if the CLI recognized the prefixes stored in the database. We will fix this in the next release.

Best,
Evren

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.