I am a relative [sic] outsider to Wikidata and I just tried to answer this question by looking at wikidata.
It turns out that there is information in Wikidata that indicates that https://www.wikidata.org/wiki/Property:P22 (father) is only to be used on people. Look at https://www.wikidata.org/wiki/Property_talk:P22, where both the type and the value type are person (Q215627), fictional character (Q95074). Similar restrictions are in place for https://www.wikidata.org/wiki/Property:P1038 (relative). So I would say that, no, you should not use these properties on horses. Whether this is a good thing or not is a separate matter. I do note that there do not appear to be any Wikidata properties that can be used for parent-offspring relationships for horses. Neither https://www.wikidata.org/wiki/Property:P22 (father) nor https://www.wikidata.org/wiki/Property:P1038 (relative) have super-properties. peter On 08/26/2015 04:45 AM, Ole Palnatoke Andersen wrote: > I've just completed #100wikidays, and my 100th article was about a > horse: https://www.wikidata.org/wiki/Q12003911 That horse is the > grandfather of https://www.wikidata.org/wiki/Q20872428, but should I > use the same properties as for humans? > > We also have https://www.wikidata.org/wiki/Q12331109 and > https://www.wikidata.org/wiki/Q12338810, who were father and son. > Again: Do we have animal properties, or do we use the same as for > humans? > > Regards, > Ole > > On Mon, Aug 24, 2015 at 10:55 PM, Andrew Gray <[email protected]> > wrote: >> Having gone and written the RFC >> (https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Merging_relationship_properties) >> I've just discovered that we *did* have this discussion in 2013: >> >> https://www.wikidata.org/w/index.php?title=Wikidata%3AProperties_for_deletion&diff=44470851&oldid=44465708 >> >> - and it was suggested we come back to it "after Phase III". I think >> the existing state of arbitrary access should be able to solve this >> problem, so I've added some notes about this. >> >> Comments welcome; I'll circulate notifications onwiki tonight. >> >> Andrew. >> >> On 24 August 2015 at 14:02, Lukas Benedix <[email protected]> wrote: >>> +1 for genderless family relationship properties. >>> >>> Lukas >>> >>>> Hi all, >>>> >>>> Thanks again for your comments. It looks like: >>>> >>>> a) there's interest in simplifying this; >>>> >>>> b) creating automatic inferences is possibly desirable but will need a >>>> lot of work and thought. >>>> >>>> I'll put together an RFC onwiki about merging the "gendered" >>>> relationship properties, which will address the first part of the >>>> issue, and we can continue to think about how best to approach the >>>> second. >>>> >>>> Andrew. >>>> >>>> On 17 August 2015 at 12:29, Andrew Gray <[email protected]> wrote: >>>>> Hi all, >>>>> >>>>> I've recently been thinking about how we handle family/genealogical >>>>> relationships in Wikidata - this is, potentially, a really valuable >>>>> source of information for researchers to have available in a >>>>> structured form, especially now we're bringing together so many >>>>> biographical databases. >>>>> >>>>> We currently have the following properties to link people together: >>>>> >>>>> * spouses (P26) and cohabitants (P451) - not gendered >>>>> * parents (P22/P25) and step-parents (P43/P44) - gendered >>>>> * siblings (P7/P9) - gendered >>>>> * children (P40) - not gendered (and oddly no step-children?) >>>>> * a generic "related to" (P1038) for more distant relationships >>>>> >>>>> There's two big things that jump out here. >>>>> >>>>> ** First, gender. Parents are split by gender while children are not >>>>> (we have mother/father not son/daughter). Siblings are likewise >>>>> gendered, and spouses are not. These are all very early properties - >>>>> does anyone remember how we got this way? >>>>> >>>>> This makes for some odd results. For example, if we want to using our >>>>> data to identify all the male-line *descendants* of a person, we have >>>>> to do some complicated inference from [P40 + target is male]. However, >>>>> to identify all the male-line *ancestors*, we can just run back up the >>>>> P22 chain. It feels quite strange to have this difference, and I >>>>> wonder if we should standardise one way or the other - split P40 or >>>>> merge the others. >>>>> >>>>> In some ways, merging seems more elegant. We do have fairly good >>>>> gender metadata (and getting better all the time!), so we can still do >>>>> gender-specific relationship searches where needed. It also avoids >>>>> having to force a binary gender approach - we are in the odd position >>>>> of being able to give a nuanced entry in P21 but can only say if >>>>> someone is a "sister" or "brother". >>>>> >>>>> ** Secondly, symmetry. Siblings, spouses, and parent-child pairs are >>>>> by definition symmetric. If A has P26:B, then B should also have >>>>> P26:A. The gendered cases are a little more complicated, as if A has >>>>> P40:B, then B has P22:A or P25:A, but there is still a degree of >>>>> symmetry - one of those must be true. >>>>> >>>>> However, Wikidata doesn't really help us make use of this symmetry. If >>>>> I list A as spouse of B, I need to add (separately) that B is spouse >>>>> of A. If they have four children C, D, E, and F, this gets very >>>>> complicated - we have six articles with *30* links between them, all >>>>> of which need to be made manually. It feels like automatically making >>>>> symmetric links for these properties would save a lot of work, and >>>>> produce a much more reliable dataset. >>>>> >>>>> I believe we decided early on not to do symmetric links because it >>>>> would swamp commonly linked articles (imagine what Q5 would look like >>>>> by now!). On the other hand, these are properties with a very narrowly >>>>> defined scope, and we actively *want* them to be comprehensively >>>>> symmetric - every parent article should list all their children on >>>>> Wikidata, and every child article should list their parent and all >>>>> their siblings. >>>>> >>>>> Perhaps it's worth reconsidering whether to allow symmetry for a >>>>> specifically defined class of properties - would an automatically >>>>> symmetric P26 really swamp the system? It would be great if the system >>>>> could match up relationships and fill in missing parent/child, >>>>> sibling, and spouse links. I can't be the only one who regularly adds >>>>> one half of the relationship and forgets to include the other! >>>>> >>>>> A bot looking at all of these and filling in the gaps might be a >>>>> useful approach... but it would break down if someone tries to remove >>>>> one of the symmetric entries without also removing the other, as the >>>>> bot would probably (eventually) fill it back in. Ultimately, an >>>>> automatic symmetry would seem best. >>>>> >>>>> Thoughts on either of these? If there is interest I will write up a >>>>> formal proposal on-wiki. >>>>> >>>>> -- >>>>> - Andrew Gray >>>>> [email protected] >>>> >>>> >>>> >>>> -- >>>> - Andrew Gray >>>> [email protected] >>>> >>>> _______________________________________________ >>>> Wikidata mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>> >>> >>> >>> >>> _______________________________________________ >>> Wikidata mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> >> >> -- >> - Andrew Gray >> [email protected] >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata > > > _______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
