Further idea... They were called Mutexes in Freebase and actually lived as part of its data. In fact, you could actually use those same rules in WD if you wanted to. In Freebase, if someone typed or classed a Musical Artist as a fictional character also...they would immediately get a warning in the GUI that they could not type as Fictional Character also.
"Musical Artist != Fictional Character" https://groups.google.com/forum/#!topic/freebase-discuss/h0LgDZIL6N4
On Mon, Jan 9, 2017 at 2:38 PM Thad Guidry thadguidry@gmail.com wrote:
Databases use schema but that doesn't mean they make sense for Humans all the time. Rules are typically used to find gaps in the data and the schema.
In Freebase, we decided to handle things such as this with Rules (as Peter leans towards), where the community would help with developing them and then we'd generate lists to have folks work on correcting the wrongful data or schema. It was all Class based rules since Freebase had multiple Classes that could be applied to a topic or entity.
I don't like Instance Of and never use it...ever...and never assert statements about it, or ask questions involving Instance Of with SPARQL...I find that WD life is easier without it.
On Mon, Jan 9, 2017 at 1:17 PM Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote:
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_pap...
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 <pfpschneider@gmail.com mailto:pfpschneider@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, butWikidata is
about all >> of history, so there are many such kings. The office of "King ofIberia" 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 separateitems,
one for > the office, and one for the class. Because the individual kindshave 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 ofsimplicity. But
when you > try to write queries, this does not make things simpler, it makesit 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 theconfusion
Gerards > speaks of. There is no a priori reason that an office cannot be a class. Someformalisms
don't allow this, but there are others that do. Some sets of rulesfor
ontology construction don't allow this, but there are others thatdo. There
is certainly no universal semantic consideration, even in any strictnotion 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 woulddisallow
offices being classes. As far as I can tell, the rules forconstructing 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