For what its worth, I tend to agree with Peter here. It makes sense to me
to add constraints akin to 'disjoint with' at the class level. The
problem I see is that we don't exactly have classes here as the term is
used elsewhere. I guess in wikidata, a 'class' is any entity that happens
to be used in a subclassOf claim ?
Another way forward could be to do this using properties rather than
classes. I think this could allow use to use the constraint-checking
infrastructure that is already in place? You could add a constraint on a
property that it is 'incompatible with' another property. In the
protein/gene case we could pragmatically use Property:P351 (entrez gene
id), incompatible with Property:P352 (uniprot gene id). More semantically,
we could use 'encoded by' incompatible-with 'encodes' or 'genomic
start'
On Wed, Oct 28, 2015 at 5:08 PM, Peter F. Patel-Schneider <
pfpschneider(a)gmail.com> wrote:
I think that using P1889 in this way is abusing its
meaning.
Q16657504 P1889 Q6525093 doesn't mean that Q16657504 should not be merged
with
some other human item in Wikidata.
peter
On 10/28/2015 03:41 PM, Magnus Manske wrote:
I fear my games may contribute to both problems
(merging two items, and
adding
a sitelink to the wrong item). Both are
facilitated by identical
names/aliases, and sometimes it's hard to tell that a pair is meant to be
different, especially if you don't know about the intricate structures
of the
respective knowledge domain.
An item-specific, but somewhat heavy-handed approach would be to prevent
merging of any two items where at least one has P1889, no matter what it
specifically points to. At least, give a warning that an item is
"merge-protected", and require an additional override for the merge.
If that is acceptable, it would be easy for me to filter all items with
P1889,
from the merge game at least.
On Wed, Oct 28, 2015 at 8:50 PM Peter F. Patel-Schneider
<pfpschneider(a)gmail.com <mailto:pfpschneider@gmail.com>> wrote:
On 10/28/2015 12:08 PM, Tom Morris wrote:
[...]
> Going back to Ben's original problem, one tool that Freebase used
to
help
> manage the problem of incompatible type
merges was a set of
curated sets of
> incompatible types [5] which was used by
the merge tools to warn
users that
> the merge they were proposing probably
wasn't a good idea. People
could
> ignore the warning in the Freebase
implementation, but Wikidata
could
make it
a hard restriction or just a warning.
Tom
I think that this idea is a good one. The incompatibility
information could
be added to classes in the form of "this
class is disjoint from that
other
class". Tools would then be able to
look for this information and
produce
warnings or even have stronger reactions to
proposed merging.
I'm not sure that using P1889 "different from" is going to be
adequate. What
links would be needed? Just between a gene
and its protein? That
wouldn't
catch merging a gene and a related protein.
Between all genes and
all
proteins? It seems to me that this is better
handled at the class
level.
peter
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata