Provide an RDF mapping for external identifiers
Open, NormalPublic

Description

We want to have Wikidata as a central part of the linked data web. This means we need to not just provide the bare identifier (m1234) but also the complete concept URI (imdb.com/m1234).

These properties would be covered: https://www.wikidata.org/wiki/Special:ListProperties/external-id

External identifiers should be treated as resource references in RDF, if we know how to construct a URI from the id in the DataValue.
Such URIs con be constructed based on a URI pattern stored in the property_info table, extracted from a Statement on the property page, just like the formatter URL.

See also the relevant design document.

NOTE: implementation should be done the same way as normalized quantity values in RDF.

Related Objects

daniel created this task.Dec 11 2015, 9:35 PM
daniel updated the task description. (Show Details)
daniel raised the priority of this task from to Normal.

Change 258519 had a related patch set uploaded (by Daniel Kinzler):
RDF mapping for external identifiers.

https://gerrit.wikimedia.org/r/258519

Change 258523 had a related patch set uploaded (by Daniel Kinzler):
Collect canonical URI patterns from statements on properties.

https://gerrit.wikimedia.org/r/258523

abian added a subscriber: abian.

Note: I44a203bddfe proposes to use the same predicate for plain string IDs and URIs. We should probably use different predicates, like we do for normalized quantities.

Yes, we can't really use same predicate, OWL hates it. URIs and strings are different types in OWL, and predicate is supposed to have only one type. We don't strictly have to follow OWL (we probably already have some iffy things) but we should not do things that are clearly against it.

Also, having two things under the same predicate complicates querying as you start to get duplicates and you need to manually filter them and it's both annoying to the user and hurts query performance.

daniel added a comment.EditedOct 27 2016, 5:14 PM

So let's just define another predicate and use it. Should be simple enough. Something like ...prop/direct-resource/ perhaps? Or just ...prop/resource/ ?

daniel claimed this task.Oct 31 2016, 4:25 PM
daniel moved this task from proposed to accepted on the WMDE-TLA-Team board.Nov 1 2016, 1:43 PM
Esc3300 added a subscriber: Esc3300.Nov 6 2016, 7:24 AM

The toolserver service that currently does some of the work should probably be replaced as well.

Jonas added a subscriber: Jonas.Nov 9 2016, 6:06 PM
Ladsgroup moved this task from Proposed to Backlog on the Wikidata-Sprint board.Nov 18 2016, 10:56 AM

I'm currently considering two ways to model this:

  • add <http://www.wikidata.org/prop/direct-normalized/> as a predicate for direct statements, and use the existing "normalized" predicates for full statements: example
  • add four new predicates, <http://www.wikidata.org/prop/direct-resource/>, <http://www.wikidata.org/prop/statement-resource/>, <http://www.wikidata.org/prop/qualifier-resource/>, and <http://www.wikidata.org/prop/reference-resource/>: example

(see also: diff between examples)

daniel moved this task from Inbox to To Do on the User-Daniel board.Jan 5 2017, 7:02 PM

Note: we already have psn:, prn: and pqn: used for full normalized values. So if we want prefixes for short normalized values, we need new ones.

Then - I prefer generic "normalized value" predicate much more than specific "resource" predicate. However, the above two alternatives do not seem to be really alternatives, but rather complementary: we need predicates to express normalized value both in context of "truthy" statement and in all contexts where simple value can be encountered. That unfortunately may mean 4 new prefixes, but I currently see no way around it.

daniel updated the task description. (Show Details)Mar 21 2017, 7:23 PM