Wikidata:Bot requests/Archive/2014/08

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

drug-drug interactions

Bot for updating drug items with the statement significant drug interaction (P769), for details please see the bot's user page. AlepfuBot (talk) 08:21, 9 August 2014 (UTC)

Didn't you mean Wikidata:Requests for permissions/Bot instead? --Ricordi samoa 10:29, 9 August 2014 (UTC)

yes, sorry for the mixup --AlepfuBot (talk) 13:17, 9 August 2014 (UTC)

This section was archived on a request by: --Pasleim (talk) 17:57, 11 August 2014 (UTC)

Change statement value from Q864 to Q11281928 for the property property:P360

on this list :

Ju gatsu mikka (talk) 18:25, 22 August 2014 (UTC)

Doing with Autolist2 --ValterVB (talk) 18:45, 22 August 2014 (UTC)

Thanks Ju gatsu mikka (talk) 21:51, 22 August 2014 (UTC)

This section was archived on a request by: --Pasleim (talk) 15:50, 10 September 2014 (UTC)

Move suicide from P509 to P1196

There are 2394 statements of cause of death (P509) = suicide (Q10737) which should be moved to manner of death (P1196) = suicide (Q10737). cause of death (P509) is for medical-related causes, whereas manner of death (P1196) is about the circumstances. @Emw: --Tobias1984 (talk) 11:14, 12 August 2014 (UTC)

Support. Emw (talk) 11:51, 12 August 2014 (UTC)

Shouldn't "car accident" also be moved from cause of death (P509) to manner of death (P1196)? It isn't a medical-related cause. The manner of death would be "car accident" and the cuase of death would be something like injury (Q193078). In the same way "suicide" is the manner of death and the cause would maybe be "overdose" etc. "Cause of death = aviation accident" should also be moved. 130.88.141.34 09:31, 14 August 2014 (UTC)

@130.88.141.34: Yes that is true. traffic collision (Q9687) is also not medical related. And aviation accident (Q744913), capital punishment (Q8454), execution by firing squad (Q216169), aircraft crash (Q3002150) are also not medical. A small problem is that cs-wiki is now using p509 in one of their infoboxes and I am not sure if their infobox-code will grab the value from p1196 too. Tobias1984 (talk) 19:09, 16 August 2014 (UTC)

No, "car accident" is more appropriate for cause of death (P509) than manner of death (P1196). The two properties' descriptions address "car accident" specifically. The difference between cause of death and manner of death is not medical, per se -- it is a matter of scope. See Wikidata:Property_proposal/Archive/20#manner_of_death for background. Emw (talk) 02:29, 22 August 2014 (UTC)

@Tobias1984, Emw: This can be easily done using Autolist but having a bot is faster. I will do this if nobody disagrees. Btw I am the one who maintains infoboxes in cswiki, so I will take a look on getting both p509 and p1196. Matěj Suchánek (talk) 17:21, 23 November 2014 (UTC)

@Matěj Suchánek: Thanks for your help! --Tobias1984 (talk) 21:28, 23 November 2014 (UTC)

This section was archived on a request by: --Pasleim (talk) 09:06, 11 December 2014 (UTC)

Move claims P527 to P1383

has part(s) (P527), contains settlement (P1383)

Villages and settlements in Belgium and Netherlands (and maybe other countries) which are listed in P527 claims should be moved to a new, (better) property for this purpose (P1383). A bot should loop over all Dutch and Belgium municipalities and move P527 to P1383. Michiel1972 (talk) 13:18, 5 August 2014 (UTC)

I don't understand how this property is useful. did not has part(s) (P527) plus instance of (P31) <locality> statements did a good job ? TomT0m ^(talk) 16:44, 5 August 2014 (UTC)

True. The new property P1383 was/is in my opinion not needed, see my comment Property_talk:P1383. However, it has been used already on many items. So what to do? Michiel1972 (talk) 16:54, 8 August 2014 (UTC)

The settlements are not parts of the municipality. I would use contains the administrative territorial entity (P150), but it can't be used because of a constraint. I propose to use P1383 or merge P1383 with P150 and remove the constraint. --JulesWinnfield-hu (talk) 17:25, 8 August 2014 (UTC)

I started a deletion request because I think P527 is valid. (Wikidata:Properties_for_deletion). Michiel1972 (talk) 11:40, 15 August 2014 (UTC)

Scanning off service as Roman consul

Could a bot read off en:List of Roman consuls, la:Fasti consulum rei publicae, uk:Список магістратів-епонімів Римської республіки, en:List of Roman dictators etc., and, where the name listed has a blue link, add, as appropriate, position held (P39): Roman consul (Q40779), position held (P39): consul suffectus (Q629712) (consul suffectus), or position held (P39): Roman dictator (Q236885) (dictator), with start and end dates? As an example, I did one here. N.B. some individuals (e.g. en:Lucius Papirius Cursor) held office more than once (cf. Grover Cleveland (Q35171)). It Is Me Here ^{t / c} 12:29, 17 August 2014 (UTC)

English descriptions

This section was archived on a request by: Sjoerd de Bruin (talk) 20:56, 17 February 2015 (UTC)

Would it be possible to have a bot go through the items linked on User:Haplology/a_an_the and remove "a", "an", or "the" from the beginning of the descriptions to bring them in line with Help:Description? Cheers. Del_♉sion23 (talk) 20:04, 1 August 2014 (UTC)

@Delusion23, Haplology: I could work on this, but I'm not sure if I can remove all "a", "an" and "the" at the beginning of any English description because in Help:Description it is stated that some phrases require the initial article. --Pasleim (talk) 19:23, 3 October 2014 (UTC)

Move values, qualifiers and references from instance of (P31) to heritage designation (P1435)

A new property, heritage designation (P1435), has been created for heritage monuments. Therefore, items in the following list have to be moved from instance of (P31) to heritage designation (P1435) with their qualifiers and references.

Thanks. — Ayack (talk) 19:07, 2 August 2014 (UTC)

Strong oppose to removing instance of (P31), I don't care about copying. Multichill (talk) 21:41, 2 August 2014 (UTC)

@Multichill: Could you explain why you are against this, please? Subject has already been discussed here. Thanks. — Ayack (talk) 09:22, 3 August 2014 (UTC)

@Ayack: instance of (P31) can be used for any item, as a universal Help:Classification tools. Anything can be classified as such. This is useful for tools like Reasonator who can search the nature of an item checking this property, and generic tools can show the associated subclass tree. By creating specific typing properties we break that and it's not a path I would like the project to take, it will make harder to build tools and we would have to write a lot of specific code to do things like we did with instance of (P31)/subclass of (P279). Plus in languages like OWL, a reference in the semantic web, there is strong liogical foundation for class definition, classes are defined by queries about the properties of an item (eg. the Woman class can be defined as the set of human beeings with female sex). This could prove very handy and make the whole powerful enough without the need for specific typing properties. TomT0m ^(talk) 16:54, 5 August 2014 (UTC)

Strong oppose per multichill and me. I'll add this is an opposite work comparing removing 60 Search above. If we need a direction, it's not really handy to go one step in one direction and the other step in the other. To be a little bit more soft, I'll say we can use class definitions to link the new property to the already existing classes : We can define the monument historique inscrit (Q10387575)  

class by an equivalent of the class expression this class is the class of all item who are monument with [the appropriate patrimonial status property values]. TomT0m ^(talk) 16:59, 5 August 2014 (UTC)

@TomT0m: This is not really comparable with P60 (P60). The primary p31 value for the Earth or the Sun should be something like rocky planet and yellow dwarf, so that "type of celestial object" is completely redundant with p31. Not so with heritage designation (P1435). The most obvious, and most informative, p31 values for the Palace of Versailles and Notre-Dame-de-Paris should be something like palace and cathedral, certainly not "monument historique classé. Admittedly, we can make as many p31 statements per item as we like, but putting everything in p31 is not really convenient either. For instance, if the Palace of Versailles has only "monument historique" as a P31 value, it would not be returned in a query for items with missing p31, while really it would be better if it did.

On a more structural level, I do not know know what the best supercalss for "monument histirique" should be, but something like "protection status" seems much more useful than "building", and "protection status" would hardly be a fitting superclass for the Palace of Versailles. -Zolo (talk) 17:56, 5 August 2014 (UTC)

@Zolo: We're conflating several things: The <protection status> class, as a set of status, and probably the domain of the protection status property, and the set of all monuments with some status. OWL gives us a method to link the two : let the protected palace the class of all palaces with some protection status. By definition this class is a subclass of palaces. So we can easily define <cathédrale classée> as both a subclass of <cathédrale> and <monument classé> in OWL. This saves headeachs by not to have to make sometimes difficult and arbitrary classification choices, and with a good query engine, if you query all the cathedrals instances, it will return also the instances of the subclasses. This is totally expressable with a class expression in the OWL language and a solid foundation for any classification of real world objects. As I like to say, those kind of class expression makes the definitions of a class by property not redundant : we do not have to choose beetween putting an information on instance of (P31) or in a property, as the definition of classes can be made wrt. the other properties values. Conversely, to class a cathedral, some human can conveniently only put in in the class of <cathédrale classée>, which imply it probably have a statement about its conservation status. This is very flexible. TomT0m ^(talk) 19:12, 5 August 2014 (UTC)

Of course we could say that. By the same reasoning, we could also say that there is the architectural style as a set of architectural styles and the set of all monuments with some architectural style. It would follow that we should actually have "instance of gothic cathédrale classée". Should we really create, translate and maintain items about the 10000s possible combinations like this ? The type of building has nothing to do with the protection status. Packing them in a single statement, and then unpacking them for analytical purposes adds a layer of complexity, and of fragility (every error in the subclass tree has drastic consequences). If we say that "monument historique" is an instance of protection status there is really no difficult choice. Items like "cathédrale classée" would serve no purpose and could safely be deleted.

"Instance of cathédrale classée" has various issues. A tool autodescribing Notre-Dame de Paris should say it a "cathedral", perhaps a "gothic cathedral" but certainly not "it is a cathédrale classée". And if the p31 value is "cathédrale classée", that would be very difficult to do.

"Notre-Dame de Paris is an instance of cathédrale classée" has been true only since 1862. So "instance of cathedrale classée" would be wrong without temporal restrictions. A "since 1862" qualifier may correct for this, but then we would have no p31 value for Notre-Dame before 1862. And so we would need to add a new "instance of cathedral" statement to correct for this. And then that would start to be real messy. --Zolo (talk) 20:32, 5 August 2014 (UTC)

@TomT0m, Zolo: What about McAdam Railway Station (Q287207) who have four different heritage designations? Create a instance for a unique subject is kind of useless. --Fralambert (talk) 15:16, 12 August 2014 (UTC)

@Fralambert, Zolo: Because we have some combinations does not mean we should have them all. Moreother to state that an object is an instance of several class we do not have to create an item for the most specific class we could create, we can just add several instance of (P31) statements, which will get rid of the combinatorial explosion. It's possible that there should be limit, I don't thik that really strict guidelines are really something we should fighr for when wwe can easily handle some of these class that may be of interest for some reason. There is a lot of monuments, there is less monuments that organisms decided to declare of interest, which make them particulars. TomT0m ^(talk) 12:11, 17 August 2014 (UTC)

@TomT0m:. You were proposing values like "cathédrale classée". Of course we can have "p31: classée church + P31: cathedral". That clearly requires less items, but it still suffers from the same issues. Even 1 type of heritage status with 5 types of buildings for each country requires 1000 items. And maintaining that seems tedious and pointless. And it also may cause some problems similar to that of Commons "intersection category". If you know that castle (Q23413) has many subclasses, then you know that items that are marked as "instance of castle (Q23413)" could probably use a more specific p31 value, that would better the type of building. But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated.

Actually, between the two, I like better the solution consisiting in using only values corresponding to a real heritage status ("monument historique classé" rather than "cathédrale classée), but it is still affected by the issues mentionned above. Plus, if you accept my point that it is more useful to see "monument historique" as a subclass of "legal status" than a subclass of "building", then we would have to duplicate every heritage status item ("monument historique" for heritage designation (P1435) and "monument historique building" for instance of (P31)).

Sure there are cases, were it would be nice to have info about the heritage status in p31, just like there are cases where it would be convient to have data about a person's profession in p31, but I think it is swamped by the drawbacks in terms of readability. Using p31 for the "type of building" (~form + function) is already tricky enough, better if we can avoid a new layer of complexity on the values. --Zolo (talk) 05:57, 20 August 2014 (UTC)

@Zolo: « Plus, if you accept my point that it is more useful to see "monument historique" as a subclass of "legal status" than a subclass of "building" » Not only I don't accept it, I think this is totally ill defined and not correct. Do we really have a set of particular status, who forms a class of legal status here ? Then monument historique classé is a class of legal status indeed, whose instances are particular legal status. But then the label is misleadinq : it is referring to monuments, not to legal statuses, which suggests its instances are monuments. A better label could then be "statut de monument historique classé". Actually the item about the class of monuments already exists, see Historical Monument (Q916475)  

, note that the introduction sentince of the french article is « Un monument historique est, en France, un monument ou un objet recevant par arrêté un statut juridique destiné à le protéger » which is pretty much exactly what I'm trying to express. I think the «Legal status» property is something different, it is more close in essence to a set of laws applying to monuments (or people, …). Note that the «monument classé» class is higher level as it regroups monuments with several particular legal statuses.

But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated. I don't really see the problem here, someone may add a more specific statement about the nature of the building as there may be several instance of (P31) statements. The combinatorial explosion problem ruled out, I don't understand what problem there is, having a legal status property is absolutely not mutually exclusive, it might not have the same granularity of the general classification system. The problem I see with discriminating the classes we can create wrt. instance of (P31) and the classes if that it is very subjective and that you can use a lot of criteria to class building. Deciding that the castle cathedral axis is better than the building is better than the material they are made of axis as main criteria is not up to us. But what's for sure is that the classe/non classe axis is of general interest : the article preexists. But I think that classes, as a generic mechanism, needs more specific properties (like properties expressing the intended usage of a building or object, or the kind of material he is made of). This indeed can help to define classes of buildings. This needs a little bit of judgment to choose them but I'm against hard principles like intersected categories are evil, the Historical Monument (Q916475)  

proves, although it is the intersection of building and object with a legal status, that it is a class of interest.

I realize my initial position was maybe a little hard : I'm for the introduction of the legal status property, I'm just not for the deletion of every and all of the classes. I wold add that it as several advantages : the whole class tree can be presented using templates like {{Classification}} or reasonator, which alloas to present in a concise way with a granularity someone may understand : you may not be am expert in legal statuses but know what a «monument classé» is, the hierarchical nature of classes allows to presnt the relevants information at several granularities in a concise way. Good choices for classes will allow us to be efficient into presenting informations about an item in a useful way both for experts and nonexpert, maybe it should be one of the principles who will guide us in item classification.

@Zolo: One more thought That jist occured to me, about combinatorial explosion and queries : I don't think queries will be of any help in the forseable dev plans: we will have to create an item per query. Which means queries will suffer the exact same problems with intersections and won't help keep the number of items down. Therefore, as both queries and classes are associated to a set of instances in one case and results in the other, they are conceptually very similar and two faces of the same coin. TomT0m ^(talk) 14:20, 20 August 2014 (UTC)

@TomT0m: But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated.. What I meant is that the most useful subclasses of castles are things that tell you what type of castle this is. motte-and-bailey castle (Q92062) is a type of castle (a castle built on a motte etc.). But "classé castle" is not really a type of castle - it is just a castle that is at the same time a monument historique classsé. Suppose an expert wants to add better p31 values for castles. The most obvious starting point would be to look for items that are instances of castle, but not instances of subclasses of castle. If something is "p31: classé castle", it will not appear in the list.

We could also get around this issue by using classes like: "castle by type" and "castle by protection level", but that requires a really well maintained class system, and I do not think we should count on that yet.

This question is not really the granularity level but rather: what sort of information do we expect to find in p31. We have separate properties for the architectural style, the material used, the protection status. If we are looking for information about that, we should rather use those properties. Repeating them in p31 has probably some benefits, but it also makes a lot of not-very-useful redundancy and makes the structure of the item harder to grasp.

What I seem to guess from meta:Wikidata/Queries is that it will (at some point) be possible to make queries based on several property-value cconstraints, but it may not be possible to do queries based on subclasses. This would make "intersection items" like "classé castle" unnecessary - and even harmful if this leads some user to remove the additional "instance of castle" that would be of use in other queries. --Zolo (talk) 15:15, 21 August 2014 (UTC)

@Zolo: I think you don't really understand really well the foundations of instance of (P31)/subclass of (P279). We can totally call a type of castle a castle of a certain architectural style of some time period, because experts, for some reason, usually treats those castles together. The solution to group the classes in metaclasses is a promising path : It could gives good foundations to our classes. If an expert built a classification of castles using some criteria, we can regroup the classes he created in a metaclass, and make the classes instances of this metaclass. He could have used any criteria to regroup the castles, he could build a class "medieval castles" because they are very different from post-medieval ones, yet the information is redundant with the year the castle was built. Yet he built a class of castles, and <medieval castle> will be a type of castle in his classification. I don't think it is especially hard to maintain if we find good classifications in litteratures. Good classifications are built with some criteria, this criteria might be informations we already have about castles with other properties. TomT0m ^(talk) 16:27, 21 August 2014 (UTC)

@TomT0m: i don't know what makes you think I don't understand the foundations of instance/subclass. By type of building, I just mean its purpose/architectural pattern, not anything ontological. That would be the "dénomination" parameter of Mérimée's monuments historiques database (if you don't mind terrible ergonomy, you can find it at http://www.culture.gouv.fr/culture/inventai/patrimoine/ -> vocabulaires -> type d'édifice -> liste hiérarchique).

I am not saying it is wrong to use p31 for protection status (depending on how the protection-status items are defined), just that it is not convenient. If we have two separate metaclasses "building by type" and "building by status", that may be manageable, but still much more complicated than using separate properties. --Zolo (talk) 16:55, 21 August 2014 (UTC)

@Zolo: It's because you seem to argue that instance of (P31) is mainly here to add information about the castle that is not present in the other properties. Actually it is quite the opposite : What defines the type of an item is exactly its properties, and we only have a fraction of its properties in the database, and we regroup in classes items with somehow similar properties. Actually I would not oppose having a purpose and architectural pattern properties. Then if we can class buildings (not castle suddenly :)) using their purpose and build patterns. Actually this would make explicit which criteria are relevant to class those objects, even if it is a combination of properties, which is actually very often the case. I think if we do not reason like that this defeats the purpose of having a unique main typing property and we can consider almost each properties as typing properties. The merimée database hierarchical classification of building is clearly a classification choice : The class building first by purpose, putting every building related to the army in the same class. I think it's a legitimate choice and I would support having such a class in Wikidata, which in turn could be marked as instance of <Mérimée building classification class>. But other organisms could class building using other criteria or other hierarchy and that would be another legitimate choice. Another more technical reason, classes are used to be the domain and range of properties. If we know that a certain type of building has always some property, and that it does not follow a natural community classification hierarchy, then it could be technically convenient to create the class to express easily constraints about the domain and ranges of the property for example. If, this does not fit in Mérimée classification, for example if a property apply to buildings in a certain area, then we would have to not follow it and put classes for some castles that absolutely do not follow this scheme. In short I don't think that what you are looking for here to state architectural patterns or purpose of a castle is instance of (P31)/subclass of (P279) at all. Those two properties are more synthetic way of giving information about their instances : if you know an item is a human, this is a lot of informations already. But classes can't solely gives information not countained in the properties of an item, whether or not Wikidata is powerful or complete enough to know them. TomT0m ^(talk) 18:44, 21 August 2014 (UTC)

@TomT0m:. I do not think the purpose of p31 is to put things that we do not know where to put, but rather that it should be only contains a few values that describe most relevantly and most durably what sort of thing the item is. Just like we use human (Q5) for humans, rather than the tons of other things that individuals are instances of.

I agree that we should try to define better critera for classifying buildings, but the way the "type of building" (church, castle...) mixes purpose and form of the building is rather tricky. I think most people would still call a disused church an instance of church, but inferrence wise, it would not be really compatible with church building (Q16970)has use (P366)cult (Q756820)

@Zolo: It is compatible. It's easy to make the link. Let's define «a church» «a building that once has been used for cult». That should be possible using a well grounded classification systems like OWL classes defined by class expressions (although it does not uses qualifiers), informaly at least. I disagree with your instance of (P31) intended usage, it should be more powerful than that and should allow different POV expressions. Even more advanced classification than just those for which most people would agree on. Even maintenance classes like we have maintenance categories. The question is whether or not those two goals are compatibles and what to do if they are not. Maybe ranking is a partial answer. I think that commons cat are a reference: I think our classification system should allow to do everything commonscat achieves, but in a better defined way. I don't think queries are the ultimate answer to this as both an index-style information browsing and queries have their usefulness, and because good classifications ARE actually knowledge. And sourcable one sometimes. And queries can be hierarchically ordered, just like classes, by for example inclusion of their results. Just using arbitrary queries allows us not to make classification choices. But maybe it would be a lost opportunity to express valuable knowledge in a well thought and defined OWL-like way, and profit the associated toolset and community knowledge (dbpedia uses classes a lot for example). TomT0m ^(talk) 12:29, 22 August 2014 (UTC)

@TomT0m: to me "use" would be most naturally interpreted as current use (for instance, a disuses church should not appear on a map of cult facilities. There are certainly ways to solve this, but it would mean using somewhat more complicated solution that "some church instance of church; church: use: cult". Anyway, this is probably not the right place to discuss it. --Zolo (talk) 05:56, 23 August 2014 (UTC)

Of course, it's a simple example. But an illustrative one actually : in different context what we refer to a church may differ, which makes not so simple a single value instance of guideline. But in Wikidata (temporal) qualifiers can be a real help to model things : let define a repurposed church a building who had a religious purpose but another usage nowdays.

@Zolo: I guess at that point we can only act the disagreement. I am totally on the same page with Nemo_bis on your initial discussions on the Wikiproject page, I think the issues you mentions about creating a lot of items are not valid. I think OWL class expressions are a really solid base for a generic constraint system ( a little bit too solid actually as we can't use it yet:) ). I can fear emerging tensions between those who understand well our generic classification system and can quickly add relevant classes to items without a lot of noise and quircks and those who will take a longer path with a lot of discussions and all, with imho no clear really outcome, the subclass hierarchy here seemed really fine to me, the objects are classes, and we can(ould)? query them as instances of some metaclass. Maybe what would be important is to make our constraint system more expressive, this would make Fralambert's argument less relevant (Pinging them ^^), is there a Ping project ? this could accelerate the decision, we are not really good at decision making, which is why I enjoy the quiet generic path :) TomT0m ^(talk) 09:29, 23 August 2014 (UTC)

@Zolo, Fralambert: A more expressive constraint system will be surely welcome. Like Wikidata:Database reports/Constraint violations/P1435 not realy work like I like (I don't want the subclasses of the item, but the list of item itself. The main reason that I approve the cration of P1435 is that the number protection statuses is really diverse. If you look this document between the page 57 and 63, you can see all the possible result only for Canada. There is actually 5 differents protection statuses for the Federal and 13 for my province (Quebec). The other problem is the is not a international register (or at least a international codification like (WDPA ID (P809) for protected area). To have something for see result like http://tools.wmflabs.org/wikidata-todo/autolist.html?q=CLAIM[17%3A39]%20AND%20CLAIM[1435] is to much to ask? --Fralambert (talk) 14:44, 23 August 2014 (UTC)

@TomT0m: Is heritage designation (P1435) a subproperty of instance of (P31)? If so, does it matter much to use heritage designation (P1435) instead of instance of (P31), but with the benefit of having specific constraints?--Micru (talk) 14:59, 23 August 2014 (UTC)

Micru, there are no subproperties of instance of (P31). Instance of has the semantics of rdf:type and subproperties of rdf:type are not valid in OWL 2 DL. Emw (talk) 15:24, 23 August 2014 (UTC)

@TomT0m, Emw:. I played around a bit with the data in the past few days. It is true that using p31 as catchall can be convenient. See Template:Is a that returns true if param 1 is an instance of param 2. Stil, and even though they are not standard, I think subproperties of p31 could bring the best of both worlds. --Zolo (talk) 09:06, 27 August 2014 (UTC)

It seems we don't have any consensus on what to do about the change from instance of (P31) to heritage designation (P1435) . I am concerned that the lists may be diverging as some editors make the change manually, so that neither query will return a complete list. Is there somewhere else that this has been discussed that I missed? - PKM (talk) 02:52, 23 November 2014 (UTC)

discussion continued on Wikidata talk:WikiProject Cultural heritage#Irksome issues with p31--Pasleim (talk) 10:06, 21 January 2015 (UTC)

This section was archived on a request by: --Pasleim (talk) 15:43, 28 February 2015 (UTC)