Daniel, it is not so clear cut. Most users will not be exposed to a
"zoo". Case in point - Open Street Map. In OSM, the entire user base of
tens of thousands of people know the meaning of Q123. The "Q" prefix has a
strong identity in itself. Anyone will instantly say - yes, it's a
Wikidata identifier attached to the majority of important OSM objects. So
whenever someone sees an object with the tag "wikidata=Q123" or
"brand:wikidata=Q123" or even "species:wikidata=Q123" they know that
there
is a WD item describing this object, or the brand of this object (e.g.
Mc.Donalds store), or the tree species.
As Lydia said, Wikidata is a huge tree in a forest, overshadowing all other
trees. It is totally ok for both OSM and some genetics storage to both use
the same prefix - there will be no confusion between the users of the two.
Yet both of them are likely to reference Wikidata itself. Keeping "Q" as
primarily Wikidata identifier will help the users. That's why I call this
a philosophical debate - on one hand, there is very real usability problem.
On the other, there is a philosophical dilemma - the best approach in a
hypothetical world.
Now that we also have Wikibase on OSM wiki, all of the metadata about those
tags is also stored in the Q numbers. So "wikidata" key itself is Q827
[1]. Now lets say at some point we decide to store an item's "class" in
osm Wiki, e.g. "item_class=Q123". How often do you think users will
confuse this Q123 to be wikidata's ID vs OSM wiki ID? This is almost
certain to cause confusion, especially among the novice users, without
actually benefiting anyone except the philosophical "everything must be a
prefix". Note that unlike Mediawiki, there are hundreds of different tools
in OSM, and they do not share anything except key-value pairs. So it would
not be possible to make the same "smart" interface for each of them.
People will have to use Q123 as a string.
Lastly, up until this morning, the Query Service hardcoded wd:, wdt:, and
other prefixes to always mean "current wiki" (conceptUri), which obviously
was very confusing -- wd:Q123 had different meaning depending on where you
ran it, and if you used federation query with Wikidata itself, you had to
hardcode a new prefix into your query to revert the meaning of wd: back to
wikidata's. Luckily, it wasn't too hard of a fix that I hope will be
merged soon [2].
[1]
https://wiki.openstreetmap.org/wiki/Item:Q827
[2]
https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/476398
On Wed, Nov 28, 2018 at 8:03 PM Daniel Kinzler <dkinzler(a)wikimedia.org>
wrote:
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