and the class of items that can have occupation:politician should be 'person' not 'human'. 'person' as defined by VIAF could include Stubbs the cat-with-a-name, as well as fictional humans etc. so Stubbs would be <instance of:cat with a name> which would be <subclass of:person> and <subclass of:cat> or maybe Stubbs <instance of:cat> and <instance of:non-human politician>. or maybe the constraint should be property 'occupation' has domain:person and domain:Stubbs. Yeah I like that last one best.
I think the difference between 'occupation' and 'profession' is that if a cat can do it then it's an 'occupation'.
Yes the class tree needs work, especially the higher levels, and copying someone else's High Level Ontology seems to be impractical as they all seem to be copyrighted. I hope that this is the kind of thing that will get better with time. We will see.
Joe
On Thu, Aug 27, 2015 at 12:07 AM James Heald j.heald@ucl.ac.uk wrote:
On 26/08/2015 23:35, Svavar Kjarrval wrote:
On mið 26.ágú 2015 19:24, Joe Filceolaire wrote:
Every other ontology mixes humans with fictional characters and with groups of humans and possibly fictional humans (biblical characters for instance). Wikidata has gone to a lot of trouble to try to untangle these into separate classes. Anyone trying to get an exhaustive list of humans and not using <instance of:human> deserves everything he gets.
P21 (sex or gender) is very explicitly specified as being usable for humans and for other creatures. At the request of some languages we have separate items for 'female human' and for 'female creature' (we have the same for male), 'Female human' is 'subclass of:female creature'. Relying on P21 to tell if something is or is not human is not recommended as it will probably miss out all the humans who are neither male nor female - wikidata has about a dozen other values that can be used with this property.
Father (P22) and mother (P25) can perfectly well be used for non-humans and if the current constraints on these properties flag this as a problem then the constraints will have to be updated. I expect to see extensive pedigrees for racehorses entered in Wikidata. Note that there is a proposal under consideration to replace P22 and P25 with a single 'parent' property.
Hope this helps
Joe
For me, it doesn't help. One of the purposes of Wikidata is that it should also be machine readable. If I were trying to, for example, travel recursively through the declarations to find deep common facts about some group of items, it would take much more work than necessary if I have to hunt down and code around a lot of wrongly categorised trees and special cases in the data structure.
One other example is Stubbs, the current mayor of Talkeetna, (Q7627362) which happens to be a cat. The Wikidata item for Stubbs has the declaration P31->Q146 (cat). However, it also has the definition P31->Q30185 (mayor), a subclass of Q2285706 (head of government) which is a subclass of Q82955 (politician) and that's finally a subclass of Q5 (human). One might suggest that since the item for Stubbs is specifically declared as a cat, that definition has priority (or some variation of that logic). The problem is that a machine cannot automatically understand that. Without special programming and/or a way to define contradictions like that in Wikidata, both facts are assumed to be correct. The machine might not even know that there is a contradiction at all so the machine, in its inferences, will assume Stubbs is both a human and a cat.
- Svavar Kjarrval
There are a *lot* of problems with P279 (subclass), right across Wikidata.
These will only be corrected once people start doing searches in a systematic way and addressing the anomalies they find.
In this case, politician (Q82955) should *not* be a subclass of human (Q5), instead it should be a subclass of something like occupation (Q13516667), or alternatively perhaps profession (Q28640).
My understanding is that currently there are a vast number of incorrect subclass relationships in the project, messing up tree searches, and so far it is something that has simply not yet been systematically addressed.
-- James.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata