Although there is no formal problem here, care does have to be taken when modelling entities that are to be considered as both classes and non-classes (or, and especially, metaclasses and non-metaclass classes). It is all too easy for even experienced modellers to make mistakes. The problem is worse when the modelling formalism is weak (as the Wikidata formalism is) and thus does not itself provide much support to detect mistakes. The problem is even worse when the modelling methodology often does not provide much description of the entities (as is the case in Wikidata).
The paper that Denny cites proposes that each entity be given a level (0 for non-class entities and some number greater than 0 for classes). The instance of relationship is limited so that it only relates entities to entities that are a single level higher and the subclass of relationship is limited to that it only relates entities within a single level. This rules out the problematic earthquake (Q7944), which used to be both an instance and a subclass of natural disaster (Q8065), and white (Q23444), which is currently both an instance and a subclass of color (Q1075). Although neither of these situations is a formal failure they are both almost certainly modelling failures. It is, however, useful to be able to model entities that do not fit into this modelling methodology, like the class of all classes. These exceptions are, I think, rare. Anyway, what this points out is that there are problems in how Wikidata models the world. Better guidelines on how to model on Wikidata would be useful. Strict rules, however, can easily prevent modelling what Wikidata should be modelling. My suggestion is that Wikidata classes should have more information associated with them. It should be possible for a modeller to easily determine how a class is supposed to be used. This is not currently possible for color and I think is the main source of the problems with color. Peter F. Patel-Schneider Nuance Communications On 01/09/2017 10:28 AM, Denny Vrandečić wrote: > I agree with Peter here. Daniel's statement of "Anything that is a subclass of > X, and at the same an instance of Y, where Y is not "class", is problematic." > is simply too strong. The classical example is Harry the eagle, and eagle > being a species. > > The following paper has a much more measured and subtle approach to this > question: > > http://snap.stanford.edu/wikiworkshop2016/papers/Wiki_Workshop__WWW_2016_paper_11.pdf > > > I still think it is potentially and partially too strong, but certainly much > better than Daniel's strict statement. > > > > On Mon, Jan 9, 2017 at 7:58 AM Peter F. Patel-Schneider > <pfpschnei...@gmail.com <mailto:pfpschnei...@gmail.com>> wrote: > > On 01/09/2017 07:20 AM, Daniel Kinzler wrote: > > Am 09.01.2017 um 04:36 schrieb Markus Kroetzsch: > >> Only the "current king of Iberia" is a single person, but Wikidata is > about all > >> of history, so there are many such kings. The office of "King of > Iberia" is > >> still singular (it is a singular class) and it can have its own > properties etc. > >> I would therefore say (without having checked the page): > >> > >> King of Iberia instance of office > >> King of Iberia subclass of king > > > > To be semantically strict, you would need to have two separate items, > one for > > the office, and one for the class. Because the individual kinds have not > been > > instances of the office - they have been holders of the office. And they > have > > been instances of the class, but not holders of the class. > > > > On wikidata, we often conflate these things for sake of simplicity. But > when you > > try to write queries, this does not make things simpler, it makes it > harder. > > > > Anything that is a subclass of X, and at the same an instance of Y, > where Y is > > not "class", is problematic. I think this is the root of the confusion > Gerards > > speaks of. > > There is no a priori reason that an office cannot be a class. Some > formalisms > don't allow this, but there are others that do. Some sets of rules for > ontology construction don't allow this, but there are others that do. > There > is certainly no universal semantic consideration, even in any strict > notion of > semantics, that would require that there be two separate items here. > > As far as I can tell, the Wikidata formalism is not one that would > disallow > offices being classes. As far as I can tell, the rules for constructing > the > Wikidata ontology don't disallow it either. > > Peter F. Patel-Schneider > Nuance Communications > > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wikidata > > > > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
