Markus,

On Thu, May 29, 2014 at 12:53 AM, Markus Krötzsch < markus@semantic-mediawiki.org> wrote:

This is an easy question once you have been clear about what "human behaviour" is. According to enwiki, it is a "range of behaviours *exhibited by* humans".

Settled :) Let's leave it at <defined as a trait of>

What would anybody do with this data? In what application could it be of interest?

Well, our goal it to gather the whole human knowledge, not to use it. I can think of several applications, but let's leave that open. Never underestimate human creativity ;-)

Moreover, as a great Icelandic ontologist once said: "There is definitely, definitely, definitely no logic, to human behaviour" ;-)

Definitely, that is why we spend so much time in front of flickering squares making them flicker even more. It makes total sense :P

I think "constraints" are already understood in this way. The name comes from databases, where a "constraint violation" is indeed a rather hard error. On the other hand, ironically, constraints (as a technical term) are often considered to be a softer form of modelling than (onto)logical axioms: a constraint can be violated while a logical axiom (as the name suggests) is always true -- if it is not backed by the given data, new data will be inferred. So as a technical term, "constraint" is quite appropriate for the mechanism we have, although it may not be the best term to clarify the intention.

Ok, I will not fight traditional labels nor conventions. I was interested in pointing out to the inappropriateness of using a word inside our community with a definition that doesn't matches its use, when there is another word that matches perfectly and conveys its meaning better to users.

Some important ideas like classification (instance of/subclass of) belong

completely to the analytical realm. We don't observe classes, we define them. A planet is what we call a "planet", and this can change even if the actual lumps in space are pretty much the same.

Agreed. Better labels could be <defined as instance of>/<defined as subclass of>

Now inferences are slightly different. If we know that X implies Y, then if "A says X" we can infer that (implicitly) "A says Y". That is a logical relationship (or rule) on the level of what is claimed, rather than on the level of statements. Note that we still need to have a way to find out that "X implies Y", which is a content-level claim that should have its own reference somewhere. We mainly use inference in this sense with "subclass of" in reasonator or when checking constraints. In this case, the implications are encoded as subclass-of statements ("If X is a piano, then X is an instrument"). This allows us to have references on the implications.

Nope, nope, nope. I was not referring to "hard" implications, but to heuristic ones.

Consider that these properties in the item namespace: <defined as a trait of> <defined as having> <defined as instance of>

Would translate as these constraints in the property namespace: <likely to be a trait of> <likely to have> <likely to be an instance of>

In general, an interesting question here is what the status of "subclass of" really is. Do we gather this information from external sources (surely there must be a book that tells us that pianos are instruments) or do we as a community define this for Wikidata (surely, the overall hierarchy we get is hardly the "universal class hierarchy of the world" but a very specific classification that is different from other classifications that may exist elsewhere)? Best not to think about it too much and to gather sources whenever we have them ;-)

I think it is good to think about it and to consider options to deal with it. Like for instance: <defined as instance of> "corresponds with item" <Wikimedia community concept> We already have items that refer to concepts that only make sense for us, so no change in that regard.

At the moment, hard constraints (from definitions) and soft constraints

(expectations) are simply mixed, and maybe this is fine since we handle them in a similar fashion (humans need to look how to fix the situation). Most constraints, even those that refer to definitions, are rather soft anyway since we apply them to statements, not to hard facts. Hard constraints can only occur in cases where the *encoding* of a statement in Wikidata is wrong (not the intended statement as such, but how it was translated to data).

As explained above, expectations inferred from definitions should not be treated as hard constraints, but as soft ones.

Micru

On 29/05/14 12:41, Thomas Douillard wrote:

@David: I think you should have a look to fuzzy logic https://www.wikidata.org/wiki/Q224821:)

Or at probabilistic logic, possibilistic logic, epistemic logic, ... it's endless. Let's first complete the data we are sure of before we start to discuss whether Pluto is a planet with fuzzy degree 0.6 or 0.7 ;-)

(The problem with quantitative logics is that there is usually no reference for the numbers you need there, so they are not well suited for a secondary data collection like Wikidata that relies on other sources. The closest concept that still might work is probabilistic logic, since you can really get some probabilities from published data; but even there it is hard to use the probability as a raw value without specifying very clearly what the experiment looked like.)

Markus

2014-05-29 1:48 GMT+02:00 David Cuenca <dacuetu@gmail.com mailto:dacuetu@gmail.com>:

Markus,


On Thu, May 29, 2014 at 12:53 AM, Markus Krötzsch
<markus@semantic-mediawiki.org
<mailto:markus@semantic-mediawiki.org>> wrote:

    This is an easy question once you have been clear about what
    "human behaviour" is. According to enwiki, it is a "range of
    behaviours *exhibited by* humans".


Settled :) Let's leave it at <defined as a trait of>

    What would anybody do with this data? In what application could
    it be of interest?


Well, our goal it to gather the whole human knowledge, not to use
it. I can think of several applications, but let's leave that open.
Never underestimate human creativity ;-)


    Moreover, as a great Icelandic ontologist once said: "There is
    definitely, definitely, definitely no logic, to human behaviour" ;-)


Definitely, that is why we spend so much time in front of flickering
squares making them flicker even more. It makes total sense :P

    I think "constraints" are already understood in this way. The
    name comes from databases, where a "constraint violation" is
    indeed a rather hard error. On the other hand, ironically,
    constraints (as a technical term) are often considered to be a
    softer form of modelling than (onto)logical axioms: a constraint
    can be violated while a logical axiom (as the name suggests) is
    always true -- if it is not backed by the given data, new data
    will be inferred. So as a technical term, "constraint" is quite
    appropriate for the mechanism we have, although it may not be
    the best term to clarify the intention.


Ok, I will not fight traditional labels nor conventions. I was
interested in pointing out to the inappropriateness of using a word
inside our community with a definition that doesn't matches its use,
when there is another word that matches perfectly and conveys its
meaning better to users.

    Some important ideas like classification (instance of/subclass
    of) belong completely to the analytical realm. We don't observe
    classes, we define them. A planet is what we call a "planet",
    and this can change even if the actual lumps in space are pretty
    much the same.


Agreed. Better labels could be <defined as instance of>/<defined as
subclass of>

    Now inferences are slightly different. If we know that X implies
    Y, then if "A says X" we can infer that (implicitly) "A says Y".
    That is a logical relationship (or rule) on the level of what is
    claimed, rather than on the level of statements. Note that we
    still need to have a way to find out that "X implies Y", which
    is a content-level claim that should have its own reference
    somewhere. We mainly use inference in this sense with "subclass
    of" in reasonator or when checking constraints. In this case,
    the implications are encoded as subclass-of statements ("If X is
    a piano, then X is an instrument"). This allows us to have
    references on the implications.


Nope, nope, nope. I was not referring to "hard" implications, but to
heuristic ones.

Consider that these properties in the item namespace:
<defined as a trait of>
<defined as having>
<defined as instance of>

Would translate as these constraints in the property namespace:
<likely to be a trait of>
<likely to have>
<likely to be an instance of>


    In general, an interesting question here is what the status of
    "subclass of" really is. Do we gather this information from
    external sources (surely there must be a book that tells us that
    pianos are instruments) or do we as a community define this for
    Wikidata (surely, the overall hierarchy we get is hardly the
    "universal class hierarchy of the world" but a very specific
    classification that is different from other classifications that
    may exist elsewhere)? Best not to think about it too much and to
    gather sources whenever we have them ;-)


I think it is good to think about it and to consider options to deal
with it. Like for instance:
<defined as instance of> "corresponds with item" <Wikimedia
community concept>
We already have items that refer to concepts that only make sense
for us, so no change in that regard.

    At the moment, hard constraints (from definitions) and soft
    constraints (expectations) are simply mixed, and maybe this is
    fine since we handle them in a similar fashion (humans need to
    look how to fix the situation). Most constraints, even those
    that refer to definitions, are rather soft anyway since we apply
    them to statements, not to hard facts. Hard constraints can only
    occur in cases where the *encoding* of a statement in Wikidata
    is wrong (not the intended statement as such, but how it was
    translated to data).


As explained above, expectations inferred from definitions should
not be treated as hard constraints, but as soft ones.

Micru

_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

---

Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

On 29/05/14 13:53, Thomas Douillard wrote:

hehe, maybe some kind inferences can lead to a good heuristic to suggest properties and values in the entity suggester. As they naturally become "softer" and "softer" by combination of uncertainties, this could also provide some kind of limits for inferences by fixing a probability below which we don't add a fuzzy fact to the set of facts.

Maybe we could fix an heuristic starting fuzziness or probability score based on "1 sourced claim" -> big score ; one disputed claim ; based on ranks and so on.

Sorry, I have to expand on this a bit ...

My main point was that there are many fuzzy logics (depending on the t-norm you chose) and many probabilistic logics (depending on the stochastic assumptions you make). The meaning of a score crucially depends on which logic you are in. Moreover, at least in fuzzy logic, the scores only are relevant in comparison to other scores (there is no absolute meaning to "0.3") -- therefore you need to ensure that the scores are assigned in a globally consistent way (0.3 in Wikidata would have to mean exactly the same wherever it is used).

This makes it extremely hard to implement such an approach in practice in a large, distributed knowledge base like ours. What's more, you cannot find these scores in books or newspapers, so you somehow have to make them up in another way. You suggested to use this for statements that are not generally accepted, but how do you measure "how disputed" a statement is? If two thirds of references are for it and the rest is against it, do you assign 0.66 as a score? It's very tricky.

Fuzzy logic has its main use in fuzzy control (the famous "washing machine" example), which is completely different and largely unrelated to fuzzy knowledge representation. In knowledge representation, fuzzy approaches are also studied, but their application is usually in a closed system (e.g., if you have one system that extracts data from a text and assigns "certainties" to all extracted facts in the same way). It's still unclear how to choose the right logic, but at least it will give you a uniform treatment of your data according to some fixed principles (whether they make sense or not).

The situation is much clearer in probabilistic logics, where you define your assumptions first (e.g., you assume that events are independent or that dependencies are captured in some specific way). This makes it more rigorous, but also harder to apply, since in practice these assumptions rarely hold. This is somewhat tolerable if you have a rather uniform data set (e.g., a lot of sensor measurements that give you some probability for actual states of the underlying system). But if you have a huge, open, cross-domain system like Wikidata, it would be almost impossible to force it into a particular probability framework where "0.3" really means "in 30% of all cases".

Also note that scientific probability is always a limit of observed frequencies. It says: if you do something again and again, this is the rate you will get. Often-heard statements like "We have an 80% chance to succeed!" or "Chances are almost zero that the Earth will blow up tomorrow!" are scientifically pointless, since you cannot repeat the experiments that they claim to make statements about. Many things we have in Wikidata are much more on the level of such general statements than on the level that you normally use probability for (good example of a proper use of probability: "based the tests that we did so far, this patient has a 35% chance of having cancer" -- these are not the things we normally have in Wikidata).

Markus

2014-05-29 13:43 GMT+02:00 Markus Krötzsch <markus@semantic-mediawiki.org mailto:markus@semantic-mediawiki.org>:

On 29/05/14 12:41, Thomas Douillard wrote:

    @David:
    I think you should have a look to fuzzy logic
    <https://www.wikidata.org/__wiki/Q224821
    <https://www.wikidata.org/wiki/Q224821>>:)


Or at probabilistic logic, possibilistic logic, epistemic logic, ...
it's endless. Let's first complete the data we are sure of before we
start to discuss whether Pluto is a planet with fuzzy degree 0.6 or
0.7 ;-)

(The problem with quantitative logics is that there is usually no
reference for the numbers you need there, so they are not well
suited for a secondary data collection like Wikidata that relies on
other sources. The closest concept that still might work is
probabilistic logic, since you can really get some probabilities
from published data; but even there it is hard to use the
probability as a raw value without specifying very clearly what the
experiment looked like.)

Markus

The other answers, under the original subject:

On 29/05/14 01:48, David Cuenca wrote:

Settled :) Let's leave it at <defined as a trait of>

I don't think it is very clear what the intention of this property is. What are the limits of its use? What is it meant to do? Can behaviour really be a "trait" of a species? If we allow it here, it seems to apply to all kinds of connections: density/car? eternity/time? time/reality? evil/devil? rigour/science? -- this is opening a can of worms. It will be hard to maintain this.

Wikiuser13 recently added "consists of: Neptune" to Q1. It was fixed. But it is a good example of the kind of confusion that comes from such general ontological (in the philosophical sense) properties. And "consists of" is still very simple compared to "defined as a trait of". Can't we focus on more obvious things like "has social network account" for a while? ;-)

...

Some important ideas like classification (instance of/subclass of)
belong completely to the analytical realm. We don't observe classes,
we define them. A planet is what we call a "planet", and this can
change even if the actual lumps in space are pretty much the same.

Agreed. Better labels could be <defined as instance of>/<defined as subclass of>

I don't think this is better. The short names are fine. As I explained in my email, Wikidata statements are mainly about what the external references say. The distinction between "defined" and "observed" is not on the surface of this. The main question is "Did the reference say that pianos are instruments?" but not "Did the reference say pianos are instruments because of the definition of 'piano'?" Therefore, we don't need to put this information in our labels.

Now inferences are slightly different. If we know that X implies Y,
then if "A says X" we can infer that (implicitly) "A says Y". That
is a logical relationship (or rule) on the level of what is claimed,
rather than on the level of statements. Note that we still need to
have a way to find out that "X implies Y", which is a content-level
claim that should have its own reference somewhere. We mainly use
inference in this sense with "subclass of" in reasonator or when
checking constraints. In this case, the implications are encoded as
subclass-of statements ("If X is a piano, then X is an instrument").
This allows us to have references on the implications.

Nope, nope, nope. I was not referring to "hard" implications, but to heuristic ones.

Consider that these properties in the item namespace:

<defined as a trait of> <defined as having> <defined as instance of>

Would translate as these constraints in the property namespace:

<likely to be a trait of> <likely to have> <likely to be an instance of>

I think you might have misunderstood my email. I was arguing *in favour* of soft constraints, but in the paragraph before the one about inferences that you reply to here. Inferences are hard ways for obtaining new knowledge from our own definitions. Example:

If X is the father of Y according to reference A Then Y is the child of X according to reference A

This is as hard as it can get. We are absolutely sure of this since this rule just explains the relationship between two different ways we have for encoding family relationships.

Below, you said "expectations inferred from definitions should not be treated as hard constraints" -- maybe this mixture of terms indicates that I have not been clear enough about the distinction between "inference" and "constraint". They are really completely different ways of looking at things. Inferences are something that adds (inevitable) conclusions to your knowledge, while constraints just tell you what to check for. If you accept the premises of an inference and the inference rule, then you must also accept the conclusion -- there is no "soft" way of reading this. To make it soft, you can start to formalise "softness" in your knowledge, using fuzzy logic or whatnot (see my other email with Thomas).

I don't think we can use "soft inferences" (in the sense of fuzzy logic et al.) but I am in favour of "soft constraints" (in the sense of your "expectations"). I guess we agree on all of this, but have a bit of trouble in making ourselves clear :-) But it is rather subtle material after all.

In general, an interesting question here is what the status of
"subclass of" really is. Do we gather this information from external
sources (surely there must be a book that tells us that pianos are
instruments) or do we as a community define this for Wikidata
(surely, the overall hierarchy we get is hardly the "universal class
hierarchy of the world" but a very specific classification that is
different from other classifications that may exist elsewhere)? Best
not to think about it too much and to gather sources whenever we
have them ;-)

I think it is good to think about it and to consider options to deal with it. Like for instance: <defined as instance of> "corresponds with item" <Wikimedia community concept> We already have items that refer to concepts that only make sense for us, so no change in that regard.

If you say this, then you are taking the position that instance of is defined by the community rather than being taken from external sources. My point was that such a position is not justified, given that there are so many instance of relations with references (and even qualifiers). I am unsure about the status of "subclass of" -- it could be considered a community concept or a world concept. Maybe it's best to leave this to applications that use the data.

(Btw. "corresponds with item" would be another unclear property that we should better avoid.)

At the moment, hard constraints (from definitions) and soft
constraints (expectations) are simply mixed, and maybe this is fine
since we handle them in a similar fashion (humans need to look how
to fix the situation). Most constraints, even those that refer to
definitions, are rather soft anyway since we apply them to
statements, not to hard facts. Hard constraints can only occur in
cases where the *encoding* of a statement in Wikidata is wrong (not
the intended statement as such, but how it was translated to data).

As explained above, expectations inferred from definitions should not be treated as hard constraints, but as soft ones.

As I said, hard and soft constraints would probably be treated in the same way anyway (which is the soft way), so I guess we agree here. My distinction of "hard" and "soft" constraints was about where we are getting the constraints from: some constraints are merely "usually satisfied in practice" (soft) while others are "requirements we have defined for the use of our properties" (hard). We can treat them similar, but it may still be good to understand where our "expectations" come from in each case.

Markus