Why do you have to get lost in them ?
Most already have the phrase "ID" or "Identifier" in their naming convention. So perhaps a better approach would be to standardize the naming convention used for External Identifiers and make it a best practice and golden rule during property creation and voting. A further refinement could be to enhance the statement selector with an option for "ID" or "WP ID" or "Descriptor".
I think a simple naming convention would suffice (and clean up the existing ones): <blah> ID such as for example:
CANTIC ID Freebase ID Munzinger IBA ID NLP ID dmoz ID Oxford Biography Index ID SELIBR ID etc..
Thad +ThadGuidry https://www.google.com/+ThadGuidry
On Fri, Apr 3, 2015 at 8:17 PM, Denny Vrandečić vrandecic@gmail.com wrote:
Is there any external key which is not of data type string and vice versa?
Also, no matter whether this gets done or not, please don't remove qualifiers and references from these statements (I.e. explicitly don't treat them like sitelinks)
On Fri, Apr 3, 2015, 17:36 Erik Moeller erik@wikimedia.org wrote:
Hi all --
Have we considered separating in some way (in the UI, and possibly the data model) properties which track identifiers in external databases vs. properties that describe the item using Wikidata-internal links? As more and more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l