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 < [email protected]> 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 > > <[email protected] <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > https://lists.wikimedia.org/mailman/listinfo/wikidata > > > > > > > > _______________________________________________ > > Wikidata mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikidata > > > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata >
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
