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%3FIllumi...
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@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@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