Wikidata:Requests for comment/Constraint violation technical bases

An editor has requested the community to provide input on "Constraint violation technical bases" 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. Constraint violation should be stored as statements. However, Lydia Pintscher said properties on properties can't currently be stored until we close bugzilla:49554. She currently can't give a date for that but it will not happen before the end of this year.--GZWDer (talk) 15:27, 24 November 2013 (UTC)

Introduction

P107 (P107) has been the base of some constraint violation. Now is the time to find a new technical base. This RfC will propose some of this basis, based on current Wikipedia items and properties for the type system, and globally in the spirit of Wikidata:Requests for comment/Property proposal organisation reform to a more Model (or infobox) oriented process and Wikidata:Requests for comment/Typing : class ⇄ instance relationship in Wikidata‎ on previous RfCs, which are still opened (hopefully this one will be more commented and constructive ;) )

Current state of constraint enforcement

Constraints on Properties & their combinations

Constraints have been associated to some properties, expressed with templates on their talk pages, such as those on Property_talk:P832.

These constraints, in a sense, extend the DataType of the values that a claim with this property can take, for example the date of birth property must have a date value. In the same spirit, we can define other constraints, such as Template:Constraint:Unique_value, which says that there cannot be two claims with the same property in a single item. See Category:Constraint_templates and {{Constraint}} for a list.

Constraints between classes

There exists bots that check consistency of data on the database based on some other kind of home made constraints, such as consistency between GND main type typing and (sub)class/instance of typing, for example :

User:Byrial/Class-type_conflict Items which are a subclass, but not of same GND type as the superclass
bots that uses {{Constraint:Type}} ; {{Constraint:Value type}}

Constraints are not enforced; their violations are simply listed in reports.

Principles of Data Constraints

Class constraint principle

If an item <A> is an instance of a class <C>, then it should respect constraints associated to <C>.

These constraints can define the set of statements that an instance should have.

The most important constraint is imho hasAttr, a constraint which states that all instances of a class should have one property. In the Wikidata model, it should be annotated with Qualified by. This constraint may be annotated with the number of times we should have statement with this property and qualifiers (one, any number, zero or one) ...

For example if we want to state that any book has an isbn, we should add the hasAttr : isbn constraint to the book class.

Subclasses and constraint inheritance

One of the things disputed on GND main type was its total absence of hierarchy : only one level of classification. subclass of does not have that limitation and can be used to define a hierarchy of more and more specific kinds, e.g. a skyscraper is a special kind of building. It shares some properties with all buildings, such as a location or when it was built, but can also have characteristics that only skyscraper have amongst buildings (for example criteria set by [1]).

Inheritance: If a class <B> is a subclass of <A>, then if <I> is an instance of <B>, then it is an instance of A as well.

As a consequence I should respect both constraints on class A and on class B, since it is an instance of both.

Multiple Inheritance: A class with multiple inheritance is a class that is an instance of several classes which are not subclasses of each other. Multiple inheritance is handled natively with previous definitions, as an instance of a class which inherits several other classes must respect all of their constraints. This solves the diamond inheritance problem which does not exists in this system.

For example, if we say that there is a fantasy novel class that inherits of book, that we have a hasAttr constraint associated to fantasy novel which states that a fantasy novel has at least one character statement, then Harry Potter has both an isbn statement and any number of character statements.

Extensibility

There exists other kinds of constraints; this system can be extended to take those into account, in this or in other RfCs.

instance of annotation : Some items might be instances in different times, for example a political mandate is limited in time. If we search for instances of prime ministers in all the world, should we annotate the instance of relation with a validity interval of dates ?
restrictions on values that a statement can have in certain classes. For example, if we have both Man and Woman classes, we could say that the sex property of an instance of Man is male.
... other classical constraints in ontology definition.

Workflow

We have to decide

Where to put the constraints

I see essentially two ways to express the constraints :

as statements on the class item; independently from this RfC, Wikidata:Property_proposal/Generic has some property proposed for that ;
through templates on the talk pages of class items.

How to decide it

Cathedral or Bazaar ?: Do we have to get a class modification proposal, just has we have Property Proposal ?

Relation with Property Proposals discussions: Do we need to keep property proposal or just have class modification proposals, and create properties depending on accepted class modification proposals ?

How to organize classes

Do we need an index page ? How do we navigate through classes ?

Conclusion

This first draft is intended to launch a discussion. With a few months of experience producing and editing data, we already learned a lot, new needs have emerged; I hope this proposition addresses some of the questions that the community has and will indeed be helpful for the community. Building a useful and easy (and not an annoying or blocking one) typesystem and find the common Workflow to make it work is quite an interesting challenge, let's face it !

Comments

Latest comment: 12 years ago23 comments7 people in discussion

In my opinion the better way is semi-rigid structure:

In property fields you can choose only propriety's
For property X you can choose only items that contains a property(for example) "value of property X"
A list with all value that property X can use

Benefit: more simple to mantain, less errors, less violatons Rippitippi (talk) 18:31, 4 September 2013 (UTC)

I think the constraints should be based on classes, defined by the 'subclass of' property rather than special dedicated values for each property. That way constraints can be defined without having to do thousands of changes.

For each property you can define a class for the domain (what items can have this property) and a class for the range (what items can this property link to).

Later we should be able to define special constraints - "if the Domain is in this class then the Range will be that class".

A class is defined as all the items which are 'instance of' (or other equivalent properties such as 'type of administrative unit') that class or a subclass of that class.

First step: Create a list of every 'instance of' statement that points to an item which does not have a 'subclass of' statement. Check these and add 'subclass of' statements as required.

Agreed. Also any "class" item that currently bears a GND type other than "term" is likely improperly defined. - LaddΩ chat ;) 16:56, 20 September 2013 (UTC)

Second step: Create a visualisation of the hierarchy created using the 'subclass of' property. Add 'subclass of' statements where needed to complete the hierarchy.

--Filceolaire (talk) 21:15, 4 September 2013 (UTC)

We miss one think with deleting P107. P107 is single-value property. All items are divided to non-intersected classes. For example this error will be detected by constraint report. How we will detect this error type in case of P31/P279? — Ivan A. Krestinin (talk) 19:07, 18 September 2013 (UTC)
It seems related to the disjoint with constraint on classes, which states that an instance of one of the class can not be an instance of the other one. It seems relevant to put on some higher level in the hierarchy classes, like a beeing can not be an instance of a place, for example. TomT0m (talk) 19:18, 18 September 2013 (UTC)
Support, disjointness of classes should be given for more general classes so as to reduce the overall number of such constraints that are needed (and that need to be maintained). --Markus Krötzsch (talk) 17:27, 20 September 2013 (UTC)

Most negative constraints (disjoint with, must not have property and etc.) have one bad side: the number of such constraints can be very high. It will be hard to manage its. Placing to more general classes solve part of this problem, but only part. — Ivan A. Krestinin (talk) 15:29, 22 September 2013 (UTC)
That's true. We should only put these constraint if there is an experienced based good reason, such as a common mistake is by contributors that could be checked by that. Is there a lot of positives in the GND based equivalent ? TomT0m (talk) 15:41, 22 September 2013 (UTC)
468 positives for GND. — Ivan A. Krestinin (talk) 17:46, 22 September 2013 (UTC)
I checked a few lile SDZ (Q562754), it's not a disjoint class problem, it's an (exact duplicate statement for no reason. It would require a general sanity check to avoid this ... It seem to be something more general and not related to disjoint classes. The other one I checked are disambiguation pages who are also terms, which is weird but also related to GND weirdness in itself, a disjoint with constraint in higher level classes would have caught it.

Cardinality constraints to model the number of times a statement could happen would catch some of this duplication errors, but they are trickier as different sources with different opinions might duplicate the statements, so we will need to think and discuss that a little mre. TomT0m (talk) 18:06, 22 September 2013 (UTC)

Another problem : Kunst Museum Winterthur | Reinhart am Stadtgarten (Q689829) with a museum, which is somewhat a larger problem with no real easy answer (several items, one for the building and one for the organization), and could also be cought with disjoint with and a classical mistakes policy : we create a constraint for an identified problem. TomT0m (talk) 18:27, 22 September 2013 (UTC)

Where to put the constraints

In my opinion the constraints should be attached to the Properties, just as they are now. The constraints will define

the Domain of the property - the Class of items which can use the property and
the Range of the property - the Class of items the property can point to.

The next level of sophistication is to add conditionals to these constraints. If the Subject is a member of Class A then the range is Class B but not Class D. I think this entire RFC needs to get rewritten around this concept. Filceolaire (talk) 16:25, 19 September 2013 (UTC)

May I ask why ? Put constraints on classes has at least one advantage : all the information is available by checking the class item and its parents, and not all the properties one by one. Usually a user does not want to use a property, he wants to describe an object of some sort and know how to do this. Know with a property centered paradigm, has has to find the property by trial and mistake, which is in my humble own time consuming and tedious. Putting constraints on class items allows to have a bird eye view (plus additinaly constraints can be put on properties just as know). The conditional constraint on properties solution would put a lot of informations in the wrong place. Lets take a widely used properties, in a lot of contexts, you might have a lot of conditions, and to check each of them to find the usecase you want, while all you want is to check what applies to only one kind of items. TomT0m (talk) 16:37, 19 September 2013 (UTC)

I believe constraints belong to classes; however, imho, any item with P107 (P107)==term is or can be a class - 257828 items, as of now. You'd need tools to track & propagate constraint inheritance, and we are far from there. - LaddΩ chat ;) 16:53, 20 September 2013 (UTC)

It's exactly as the constraint system right now, and as Ivan with Krbot does things : Wikibase itself is not at all involved in constraint violations of any kind except datatypes. It's up to community to write the models and to bots to check if items fits those models, and users do imports of the rdf exports in far more advanced tools. For class inheritance, yep it would be useful to have a tool but with lua and the future request enine we will get there, but it will be only useful when we will want to propose properties and qualifiers suggestion to a user when ha gave a class for an item, a gadget will be able to do that. Meanwhile we still need a replacement for P107 based constraints, this can express the constraints, they can be retrieved exactly as nows constraints or with some other kinds, and be checked and reported by bots. TomT0m (talk) 17:02, 20 September 2013 (UTC)

Interesting. So you add an 'instance of' property to an item. This then defines the class it belongs to so a tool can zip up the 'subclass of' hierarchy and give you a list of properties you can use on that item i.e. a list of properties linked to by 'domain of:P123' properties in the class items.

You pick one of these properties and an item as it's object and another tool checks that that item has that property authorised somewhere in the 'subclass of' hierarchy for that item i.e. one of the class items has a 'Range of:P123' property. Is that how it works? Filceolaire (talk) 00:29, 22 September 2013 (UTC)

It's definitly an application. To answer the "why not a simple list of properties" question, I would say "we can do that", let's call the "hasAttr" constraint "has property" constraint, make a list of "has property constraint", and there is the list of property. But we can do more, add a list of qualifier to each of these properties, add the number of time we should build statements with this property, the number of times a qualifier could be used in a statement with this property ... This sytem is actually allowing us to do this. What a bot need is the constraint. What a human need is an intelligible way of displaying this information, and tools that actually use them to guide him. Actually we already need it if we want to do the same as the current GND based constraint does. TomT0m (talk) 10:41, 22 September 2013 (UTC)

Two approaches for locating constraints

Regarding constraint locations, it would be good to look at more examples to get an idea of the problem. In general, a constraint expresses a relationship between several lasses/entities/properties, so it will always be hard to put it into one single place only. Some constraints are only about properties (example: Template:Constraint:Symmetric), other constraints relate several properties and classes/items in more complex ways (example: Template:Constraint:Target_required_claim). A constraint like "a person cannot be an event" (disjoint classes) I would argue to be only about classes: while we could say that this is a constraint about the property instance of, this would mean that we have thousands of such constraints on this single page, which would be impractical. Therefore I argue that it is not useful to allow constraints only on property (talk) pages or only on class/item (talk) pages. So what else could we do?

Approach (1): I think an ideal solution would allow users to see and edit constraints on all pages that they relate to. Example: the constraint "Target items of "father (P22)" should have a statement with "sex (P21)" and value "male (Q6581097)"" should be accessible from the pages for father (P22), sex (P21), and male (Q6581097). This does not mean that it should be part of the main statement list or of the talk pages of these pages. There should just be some way for a user who cares about constraints related to, say, sex, to find this constraint. Of course this should not mean that we have to enter the constraint three times. It should be there only once, but there should be a way to find it based on any of its parts. A further refinement of this idea would be to organise the constraints shown for each entity according to the role that the entity plays in them. In particular, it is useful to distinguish the "if" and the "then" part that most constraints have. "Father" in the example belongs to the condition that is checked to see if the constraint applies, while "sex" belongs to the requirement that this entails.

If we take the class hierarchy into account for constraints (which I strongly support), then they would also need to be shown on pages that do not occur in the constraint at all. For example, the constraint "every person should have a sex", should also appear on the page for "scientist" if we specify that scientist is a subclass of person. Again, one would prefer these "indirect" or "inherited" constraints to be displayed in another way for clarity. That's all in an ideal world, of course, and it requires new technical solutions that we do not currently have.

Approach (2): A less ideal solution is to place constraints in one single location that they are "most related to". This will usually be some entity from the "if" side of the constraint, whether property or item. It should be clear where every constraint needs to go (that is: if I exactly know the constraint I care about, then there should be one unique place where I would go to look for it). This is the current approach, where the "main place" is the talk page of the property that appears on the if side of the constraint. Maybe one could have other (possibly external) search services to be able to find a constraint if one does not care about this main element; otherwise it will really become hard to find out which constraints apply in certain cases.

There are some cases where this approach has fundamental drawbacks. For example, disjoint class constraints can never belong to only one class. The statement "A person cannot be an event" has the same meaning as "An event cannot be a person". Where should we put it then? In both places (creating redundancy)? Or on the property page (leading to a long, hard to maintain list of constraints there)? Or in one arbitrary place, such as on the talk page of the class with the smaller id (not enforceable and hard to understand)? This is one case where Approach (1) would be much nicer. --Markus Krötzsch (talk) 17:27, 20 September 2013 (UTC)

There are different groups of constraints and each group has to be handled separately:

property constraints like single value, unique value, format,... this should be managed in the talk page of the property
property constraints implying other properties or specific values for other properties (like for father with sex and male),... this should be managed in the talk page of the property
class constraints, this should be managed in a common page for classes explaining class hierarchy, mandatory and optional properties of each class (additional properties should be considered as wrong). A example of this list of mandatory properties according to a specific class can be found in help:sources. Snipre (talk) 16:28, 21 September 2013 (UTC)

If you distinguish "types of constraints", where each type has one clear place, this is what I described in Approach 2. That's fine, as long as you can make all the constraints fit somehow. My point above was that it is hard to find one unique place for some constraints anyway (since they belong equally to two or more places). If you go into more powerful constraints, things become more complex (example: "if page X has sex female and child Y, then Y should have mother X" seems to be a property constraint, but it is not clear if it should be on the talk page of child or sex). A simple scheme as you described will work for a start (basically, it is what we have now), but it's useful to understand that constraints as such do not always come with a natural page they belong to. If we would assume this, then we will indirectly forbid some constraints, not because they are hard or difficult to implement, but simply because they don't match our schema based on "constraint types". --Markus Krötzsch (talk) 14:41, 22 September 2013 (UTC)

@Snipre : your property constraints might have an if condition (we would say guard in other context) based on the class they apply to : if the subject is of some class, then we should use that kind of value. Then are they really property constraints or do they belongs to the class of items mentionned in the condition ? TomT0m (talk) 14:53, 22 September 2013 (UTC)

For the case of father, the problem is that you can apply this for several classes (animal, person, fictional chararcter) so in that case is merely a property constraint (it's definitively the definition of the constraint). We can simplify be analyzing the property use: if a property is use in an unique scheme so the constraint has to be put in talk page. If the property can be used in different ways and each way is function of a different class, we have to explain that in a central page. The idea is to avoid to repeat in the class constraints basic constraints which are applied ech time.

But first we need to list the classes and their hierarchy before any attempt to do some centralization of constraints. Snipre (talk) 11:42, 23 September 2013 (UTC)

I think it should be a bottom up approach. We should not list the classes, it's users who want a class who should propose it to community, together with a model to review (there is few reasons to refuse a class which have items, so mostly to review the model). The hierarchy will emerge in that process, and the properties will have to be chosen to fit the model, or created if nothing fits. TomT0m (talk) 11:56, 23 September 2013 (UTC)

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