@David:
I think you should have a look to fuzzy logic
<https://www.wikidata.org/wiki/Q224821> :)
2014-05-29 1:48 GMT+02:00 David Cuenca <dacu...@gmail.com>:
> 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
>
>
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
