Markus,
On Thu, May 29, 2014 at 12:53 AM, Markus Krötzsch <
mar...@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
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
