What is more problematic than the p/q business:
If I run a SPARQL search at our endpoint - such as this one:
https://database.factgrid.de/query/#SELECT%20%3FIlluminatenorden%20%3FIllum…
I will receive answers in the form of
wd:q25
but they do not lenk to wd, wikidata, but into our database
https://database.factgrid.de/entity/Q25.
The same problem in the other direction: If our users have never seen a SPARQL search in
their lives (and that's 100%) and if they now click at sample queries - they will qet
Wikidata sample queries which do not work on our database - just as our P and Q numbers do
not match.
Olaf
Daniel Kinzler <dkinzler(a)wikimedia.org> hat am
29. November 2018 um 02:02 geschrieben:
Am 28.11.18 um 10:15 schrieb James Heald:
It should also be made possible for the local
wikibase to use local prefixes
other than 'P' and 'Q' for its own local properties and items, otherwise
it
makes things needlessly confusing -- but currently I think this is not possible.
I
think the opposite is the case: ending up with a zoo of prefixes, with items
being called A73834 and F0924095 and Q98985 and W094509, would be very
confusing. The current approach is to to use the same approach that RDF and XML
use: add a kind of namespace identifier in front of "foreign" identifiers. So
you would have Q437643 for "local" items, xy:Q8743 for items from xy,
foo:Q873287 for items from foo, etc. This is how foreign IDs are currently
implemented in Wikibase.
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Schloss Friedenstein, Pagenhaus
99867 Gotha
Büro: +49-361-737-1722
Mobil: +49-179-5196880
Privat: Hauptmarkt 17b/ 99867 Gotha