Wikidata:Requests for comment/Make Symmetric & Inverse Property addition automatic and bidirectional

An editor has requested the community to provide input on "Make Symmetric & Inverse Property addition automatic and bidirectional" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!

THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Closed as stale.--GZWDer (talk) 15:52, 1 April 2014 (UTC)[reply]

Jared Zimmerman (talk) 05:56, 9 January 2014 (UTC)[reply]
Symmetric property and Inverse property are constraints currently, but would it make more sense for it to be a more integral part of the system?

for instance George W. Bush (Q207) is succeeded by Barack Obama (Q76), when this value is added to Barack Obama (Q76), should Barack Obama (Q76) is proceeded by George W. Bush (Q207) statements be automatically added to George W. Bush (Q207)?

Are there instances where this would be undesirable or illogical?

I couldn't find a list of Symmetric and Inverse properties, but working back from https://www.wikidata.org/wiki/Special:WhatLinksHere/Template:Constraint:Inverse led me to believe that there aren't any obvious places where this should not happen automatically. Thoughts?

Question What would happen if someone deleted one of the relationships after they were "filled in"? In other words, what happens after the following sequence of events:

I add George W. Bush (Q207) is succeeded by Barack Obama (Q76)
On the basis of that, some bot automatically adds Barack Obama (Q76) is preceeded by George W. Bush (Q207)
Fred comes along and deletes either of these

Presumably, the bot would re-fill-in the deleted statement, with the effect that it would be much harder to delete these relationships. Fred would have to track down all the auto-generated ones (with "symmetric" and "inverse", there could be as many as three others) and delete them all.

I am inclined to think that these statements should not be added, because they are redundant (DRY), but that they should be inferred by any query engine that acts over the data -- and I have no idea if that functionality is in the works or not.

Klortho (talk) 14:11, 11 January 2014 (UTC)[reply]

@Klortho, I wasn't suggesting a bot, I think that a background process that happens asynchronously is bad for many reasons including the one you just pointed out, I think this should be a system function that happens in real-time when the property is added to one its added to both, when removed from one, its removed from both.

Jared Zimmerman (talk) 23:40, 11 January 2014 (UTC)[reply]

For sex or gender (P21) alone there are 488 Symmetric violations, this is not good, if you take all of the Symmetric and Inverse properties i'm sure the violations are in the 10s of thousands or more, it seems quite opposite the goals of a project like this for this type of property to be handled manually rather than being a core function of the system to handle these types of properties in an automated fashion. Jared Zimmerman (talk) 01:34, 12 January 2014 (UTC)[reply]

Why not just show the properties on the Object page? edit

You propose that we automatically adding the inverse property to the page for the object of a property, pointing back to the page for the subject of the property. I would rather get rid of all the inverse properties and add a button on each item-page which would display all statements for which that item-page is the object. All these statements should also be available to a query or a wikipedia page infobox using a simple nomenclature such as '-P999' to indicate the inverse of P999.

I would be opposed to using a bot to create loads of 'inverse property statements' while we are waiting for this to be done, Filceolaire (talk) 17:23, 11 January 2014 (UTC)[reply]

@Filceolaire, I oppose using a bot for this too, see above, I don't really understand you proposal for simple nomenclature, also it seems way too technical for the casual users. We don't just want this data available via queries, if i go to one of the items "As a user i should see all information known by the system about this item on this page" rather than having to run a query to see how other items affect this one, e.g. if the item is a person family lineage should be visualized here even if reliant on other items for previous father-mother relationship, but thats another matter

Jared Zimmerman (talk) 23:40, 11 January 2014 (UTC)[reply]

I really like the idea of Filceolaire and I even could think about other extensions (to other classes of properties). Let me try to give you an example: have a look at Engelsfors trilogy (Q5377577) which is a series of books, then click on WhatLinksHere and you will discover the books in this series. Moreover, the second book Fire has not yet a link to the first book. And again WhatLinksHere helps you to find the first book. But there should be easier ways to see the relevant information. As you wrote, we want all information on one page (if it is reasonable for loading times and still humanly parsable). Until now, we only see "forward information" on pages, e.g. on the page Fire (Q5451294) you will see that Fire (Q5451294) -> part of (P361) -> Engelsfors trilogy (Q5377577). But we should also see (some) "backwards information" about the items, e.g. The Circle (Q7723069) <- followed by (P156) <- Fire (Q5451294) on the page of Fire (Q5451294), which would just be one statement stored in the page The Circle (Q7723069). This way, we only have one statement which is shown on two different pages! If we change the one statement, then clearly both appearance will be changed.

Actually, I think it is quite common with Linked Data to see also (some) backward information, e.g. "is {Property-Name} of" in dbpedia or the software package Graphite which uses the forward and backward arrows, or publication about a topic ("Thema in") in the GND, e.g. http://d-nb.info/gnd/7863462-3 , where clearly the information is stored in the bibliographic items for the individual books. --Zuphilip (talk) 19:04, 12 January 2014 (UTC)[reply]

Generalising to Constraints edit

Zuphilip has suggested to extend this feature, I agree with him.

Take France (Q142), which is instance of member state of the European Union (Q185441), and has as member of (P463) property the value European Union (Q458). Every member state of the EU should be also member of the EU, doesn't it? There should be some mechanism where one can specify for items II like member state of the European Union (Q185441), that any item F which is instance of II, should have a property X with value Y.

Currently, we have François Fillon (Q101410) with position held Prime Minister of France (Q1587677), and France (Q142) with head of government as François Fillon (Q101410). What about automatically linking both information together? head of government (P6) could have some kind of determined by some qualifier set to Prime Minister of France (Q1587677) by editors of the france item, so that head of government (P6) contains a list of all people who have the position held property as Prime Minister of France (Q1587677), including sources, start and end dates.

Second can be modelled with the constraint mechanism, first can't currently be modelled with it. Extend? Muelleum (talk) 17:27, 24 January 2014 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.