Tell me if I am right or wrong about this.
If I am coining a URI for something that has an identifier in an outside system is is straightforward to append the identifier (possibly modified a little) to a prefix, such as
Then you can write
and then refer to the concept (in either Turtle or SPARQL) as dbpedia:Stellarator.
I will take one step further than this and say that for pedagogical and other coding situations, the extra length of prefix declarations is an additional cognitive load on top of all the other cognitive loads of dealing with the system, so in the name of concision you can do something like
and then you can write :someProperty and <Stellarator>, and your queries are looking very simple.
The production for a QName cannot begin with a number so it is not correct to write something like
dbpedia:100
or expect to have the full URI squashed to that. This kind of gotcha will drive newbies nuts, and the realization of RDF as a universal solvent requires squashing many of them.
Another example is
isbn:9971-5-0210-0
If you look at the @base declaration above, you see a way to get around this, because with the base above you can write
<100> which works just fine in the dbpedia case.
I like what Wikidata did with using fairly dense sequential integers for the ids, so a dbpedia resource URI looks like
which is always a QName, so you can write
and then you can write
wd:Q4876286
<Q4876286>
and it is all fine, because (i) wikidata added the alpha prefix and (ii) started at the beginning with it, and (iii) made up a plausible explanation for it is that way. Freebase mids have the same property, so :BaseKB has it too
I think customers would expect to be able to give us
isbn:0884049582
and have it just work, but because a number is never valid in the QName, you can encode the URI like this:
and then write
isbn:I0884049582
<I0884049582>
which is not too bad. Note, however, if you want to write
<0884049582> you have to encode as
because, at least with the Jena framework, the same thing happens if you write
or
so you can't choose a representation which supports that mode of expression and a :+prefix mode.
Now what bugs me is, what to do in the case of something which "might or might not be numeric". What internal prefix would find good acceptability for end users?
--
Paul Houle
Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes
:BaseKB -- Query Freebase Data With SPARQL
Legal Entity Identifier Lookup
Join our Data Lakes group on LinkedIn