I second this. For a related effort, see:
https://github.com/pav-ontology/pav/
in particular, pav:sourceLastAccessedOn, pav:lastRefreshedOn, pav:lastUpdateOn
http://pav-ontology.github.io/pav/#d4e846
> On Jun 3, 2015, at 3:56 PM, Markus Krötzsch
> wrote:
>
> On 03.06.2015 13:57, Magnus Manske
On 03.06.2015 13:57, Magnus Manske wrote:
Maybe there is a case to separate import and verification here?
There are many statements in Wikidata nowadays, but they get really
"trustworthy" through references (other than "imported from Wikipedia").
But for external IDs, references are superfluous;
Thanks, Andrew, for the clarification. This makes perfect sense.
I don't see a problem with one bridge having two IDs in some external
database. We already have this for other ID-like properties for other
reasons. What is important though is that it still is a single bridge,
and should therefo
On 3 June 2015 at 12:48, Andrew Gray wrote:
> The lack of deduplication is probably intentional rather than a bug,
> and both entries are "correct". Perhaps one way to handle this for
> Wikidata would be to, hmm, say something like "if the item is some
> kind of a bridge, then allow two IDs" in t
Maybe there is a case to separate import and verification here?
There are many statements in Wikidata nowadays, but they get really
"trustworthy" through references (other than "imported from Wikipedia").
But for external IDs, references are superfluous; they are their own
reference, by definition
This particular case is something of a known problem - we've
encountered it with some of the other heritage-building identifier
lists as well.
Bridges often span a river which is the border for two jurisdictions
(in this case, council areas). Each local area counts it as a historic
building, and b
