Wikidata talk:Requests for comment/Migrating away from GND main type

Why is not this page a RfC ?

I don't really see the difference, and we could get rid of the announcement steps as the should be an automatic part of the RfC process. TomT0m (talk) 15:41, 18 August 2013 (UTC)

 Done --Tobias1984 (talk) 15:52, 18 August 2013 (UTC)

Constraints check

I do not understand how to migrate existing system of constraints check to new properties. Could somebody explain this process in details? — Ivan A. Krestinin (talk) 21:46, 1 October 2013 (UTC)

Your are not alone. :( --Succu (talk) 21:58, 1 October 2013 (UTC)

This RfC subject was not about constraint checking and migration, it was about data migration. But if you have questions on Wikidata:Requests for comment/Constraint violation technical bases you are of course welcome. But this system would allow to replicate the constraint system : you add hasAttr constraints about the Human class to check if the properties associated to a Human instance are the one put on the item discussion page, and so on. TomT0m (talk) 22:07, 1 October 2013 (UTC)

Subject is "Migrating away from GND main type", not "Data migrating ...". Data migration and validation procedures migration are interrelated processes. We can not start one process without another. Wikidata:Requests for comment/Constraint violation technical bases does not contain migration plan/procedure too. — Ivan A. Krestinin (talk) 22:22, 1 October 2013 (UTC)

Well, this RfC is starting to be way too long, and it's a discussion that goes way beyond GND main type. Wikidata:Requests for comment/Constraint violation technical bases and the other RfC I proposed are stepped to officialise the use of classes instead of GND main type to offer a classification scheme in Wikidata. As I see things, this RfC combined ith the others would have a result, if all sorted out :

1. We migrate person claims to instance of <human> claims
2. We move the statement constraints based on the person main type based constraints to the <human> item talkpage.

You are welcome to ask questions if there is some missing things you see.

TomT0m (talk) 08:38, 2 October 2013 (UTC)

• Looks like we have no migration plan, so I suggest the next:

1. To every property talk page add {{Constraint:Type}} or {{Constraint:Value type}} in additional to existing P107.
2. Wait when violations count will be lower then existing P107 violations.
3. Remove P107 constraint on the property page.
4. Wait until all constraints will be removed in 1-3 procedure.
5. Delete P107 claims in all elements.

— Ivan A. Krestinin (talk) 17:24, 2 October 2013 (UTC)

 Oppose not good enough, plus deserves a new RfC. Type and value type are good, but you can't handle the case where depending on the type, we exepect a new value type. That's why I would replace step 1 with, specifically for the Human class : add {{Constraint:HasAttr|P...|ValueType}} constraints to the human (Q5) talk page. It would be really easier to define new classes. TomT0m (talk) 17:50, 2 October 2013 (UTC)

Could you explain limitation of Type constraint that you mention? HasAttr on elements page is additional constraint but not replacement for current constraints. Current constrain system checks unrelated property usage. HasAttr will check data completeness. — Ivan A. Krestinin (talk) 18:04, 2 October 2013 (UTC)

Let's choose a generic authorship property, creator (P170). Depending on the type of the subject (eg. the creator of a Video game, which is a class), we might want to specify that the object is probably a game developper. Being a game developper is probably a class in itself, a subclass of P5 (P5) with the additional constraint that its occupation is main developper. We can do that if the constraint is associated to the video game class, and not to the property (or we would have possibly one constraint by creation type case in the property talk page, which is not cool). TomT0m (talk) 18:21, 2 October 2013 (UTC)

As I understand the only think that we need is specify new class developer (people or organization who develop something), subclass game developer from developer and place {{Constraint:Value type|class=developer}} to P170 talk page. Is it solve your task? — Ivan A. Krestinin (talk) 18:39, 2 October 2013 (UTC)

creator (P170) is a generic property. This means it can be used in a variety of contexts, their is creators of any kind of objects. (In Wikidata it's not so easy to create a new property as the process can be long, so I think those kind of generic properties should be given a chance.) So this imply that creator (P170) could be used with other type of items than video games, like (I don't know) a chair, an algorithm ... In each of those cases, you would have to modify the creator (P170) talk page, which could grow huge and unmaintainable. I think keep one property which can be used in a variety of contexts (on a lot of types of item), and to constraint the values of the property in each of those contexts without having to worry too much about the other one is a good idea.

Aditionally, you only have to check the video game item to see what are the type of expected creators curently in Wikidata, as well as the different style of video game class is, you don't have to guess that their is a video game style property. TomT0m (talk) 18:57, 2 October 2013 (UTC)

No need change property talk page, simple specify claim "chair" subclass of (P279) "developer" in "chair" item. — Ivan A. Krestinin (talk) 19:09, 2 October 2013 (UTC)

Sorry, I don't understand, what is ISO 3166-1 alpha-2 code (P297) ?? (and how does creator (P170) translate in Russian ? I see creator, which is the person who first had the idea and realised it). And I think you did not get the idea : the idea is that constraints will allow us to check if the datas are consistent, for example we should expect that a creator of a chair (or a model of chair) has indeed as occupation chair creator or more generally designer or a related occupation. Which would allow us to verify that a specific chair item has been created by a chair creator. TomT0m (talk) 19:21, 2 October 2013 (UTC)

Sorry, I mix P279 and P297, corrected. Now I understand. If item type is chair then creator (P170) value type must be chair creator. If item type is video game then creator (P170) value type must be video game developer. But if item type is unknown then what type must creator (P170) value be? Looks like these checks must exist in additional to existing constraints system. Current system checks: value of creator (P170) must be developer/creator. — Ivan A. Krestinin (talk) 20:11, 2 October 2013 (UTC)

If the subject class (or its superclasses) does not hasattr constraint, it's when things get interesting :) It's a new thing to investigate : either it's a genuine mistake, or it's a usecase we did not thought of yet, and it's an occasion to refine the model. But you're right, it's compatible with setting the constraints on properties. I just think constraints on classes are way more interesting, as it's more precise and it's full of information (we easily can code a gadget from that, which would take the constraints when he knows the class of the item, checks the value types, more easily than if the information is splitted all around the properties). Imho it's more interesting to focus on classes, and the constraints on properties are more or less redundant then. TomT0m (talk) 20:55, 2 October 2013 (UTC)

is a human

Don't know where to discuss so here... Why are we discussing (as a replacement to P107 (P107) person (Q215627)) instance of (P31) Homo sapiens and not instance of (P31) Homo sapiens sapiens ? Infovarius (talk) 08:59, 8 October 2013 (UTC)

We haven't been discussing it simply because noone has proposed it. It's an interesting idea though. That said, I think human (Q5) is preferable to anatomically modern human (Q5891007) because the former is the overwhelmingly more common way to classify things like Coco Chanel (Q45661) et al. Even in scientific resources, Homo sapiens far outweighs Homo sapiens sapiens as a way to refer to "modern humans". (Of course, person (Q215627) is more common still, but -- as detailed in the Coco Chanel discussion -- 'person' is unsuitably ill-defined and controversial.)

'Human' gives us an uncontroversial and well-defined concept that is also universally understood, more or less. Homo sapiens sapiens or 'anatomically-modern human' takes the "weirdness" of calling Coco Chanel human to a whole new level ("Coco Chanel is a Homo sapiens sapiens"? Yikes.). Perhaps more problematically, since Homo sapiens sapiens deals with subspecies, many inquisitive users will wonder why we don't differentiate people by race. According to Race (human classification)#Subspecies: "In biology the term "race" is used with caution because it can be ambiguous. Generally when it is used it is synonymous with subspecies.[59] For mammals, the taxonomic unit below the species level is usually the subspecies." (emphasis mine) The article Conceptualizing human variation gives a good overview. Emw (talk) 12:33, 8 October 2013 (UTC)

There is another Homo sapiens sapiens item... Infovarius (talk) 11:43, 26 January 2014 (UTC)