Further idea...
They were called Mutexes in Freebase and actually lived as part of its data.
In fact, you could actually use those same rules in WD if you wanted to.
In Freebase, if someone typed or classed a Musical Artist as a fictional
character also...they would immediately get a warning in the GUI that they
could not type as Fictional Character also.
"Musical Artist != Fictional Character"
On Mon, Jan 9, 2017 at 2:38 PM Thad Guidry <thadguidry(a)gmail.com> wrote:
Databases use schema but that doesn't mean they
make sense for Humans all
the time.
Rules are typically used to find gaps in the data and the schema.
In Freebase, we decided to handle things such as this with Rules (as Peter
leans towards), where the community would help with developing them and
then we'd generate lists to have folks work on correcting the wrongful data
or schema. It was all Class based rules since Freebase had multiple
Classes that could be applied to a topic or entity.
I don't like Instance Of and never use it...ever...and never assert
statements about it, or ask questions involving Instance Of with
SPARQL...I find that WD life is easier without it.
On Mon, Jan 9, 2017 at 1:17 PM Peter F. Patel-Schneider <
pfpschneider(a)gmail.com> wrote:
Although there is no formal problem here, care does have to be taken when
modelling entities that are to be considered as both classes and
non-classes
(or, and especially, metaclasses and non-metaclass classes). It is all too
easy for even experienced modellers to make mistakes. The problem is worse
when the modelling formalism is weak (as the Wikidata formalism is) and
thus
does not itself provide much support to detect mistakes. The problem is
even
worse when the modelling methodology often does not provide much
description
of the entities (as is the case in Wikidata).
The paper that Denny cites proposes that each entity be given a level (0
for
non-class entities and some number greater than 0 for classes). The
instance
of relationship is limited so that it only relates entities to entities
that
are a single level higher and the subclass of relationship is limited to
that
it only relates entities within a single level. This rules out the
problematic earthquake (Q7944), which used to be both an instance and a
subclass of natural disaster (Q8065), and white (Q23444), which is
currently
both an instance and a subclass of color (Q1075). Although neither of
these
situations is a formal failure they are both almost certainly modelling
failures.
It is, however, useful to be able to model entities that do not fit into
this
modelling methodology, like the class of all classes. These exceptions
are, I
think, rare.
Anyway, what this points out is that there are problems in how Wikidata
models
the world. Better guidelines on how to model on Wikidata would be useful.
Strict rules, however, can easily prevent modelling what Wikidata should be
modelling.
My suggestion is that Wikidata classes should have more information
associated
with them. It should be possible for a modeller to easily determine how a
class is supposed to be used. This is not currently possible for color
and I
think is the main source of the problems with color.
Peter F. Patel-Schneider
Nuance Communications
On 01/09/2017 10:28 AM, Denny Vrandečić wrote:
I agree with Peter here. Daniel's statement
of "Anything that is a
subclass of
X, and at the same an instance of Y, where Y is
not "class", is
problematic."
is simply too strong. The classical example is
Harry the eagle, and eagle
being a species.
The following paper has a much more measured and subtle approach to this
question:
http://snap.stanford.edu/wikiworkshop2016/papers/Wiki_Workshop__WWW_2016_pa…
I still think it is potentially and partially too strong, but certainly
much
> better than Daniel's strict statement.
>
> On Mon, Jan 9, 2017 at 7:58 AM Peter F. Patel-Schneider
> <pfpschneider(a)gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>
> On 01/09/2017 07:20 AM, Daniel Kinzler wrote:
> > Am 09.01.2017 um 04:36 schrieb Markus Kroetzsch:
> >> Only the "current king of Iberia" is a single person, but
Wikidata is
about all
>> of history, so there are many such kings. The office of "King of
Iberia" is
> still
singular (it is a singular class) and it can have its own
properties etc.
>> I would therefore say (without having checked the page):
>>
>> King of Iberia instance of office
>> King of Iberia subclass of king
>
> To be semantically strict, you would need to have two separate
items,
one for
> the office, and one for the class. Because the individual kinds
have not
been
> instances of the office - they have been holders of the office.
And they
have
> been instances of the class, but not holders of the class.
>
> On wikidata, we often conflate these things for sake of
simplicity. But
when you
> try to write queries, this does not make things simpler, it makes
it
harder.
Anything that is a subclass of X, and at the same an instance of Y,
where Y
is
> not "class", is problematic. I think this is the root of the
confusion
Gerards
speaks of.
There is no a priori reason that an office cannot be a class. Some
formalisms
don't allow this, but there are others
that do. Some sets of rules
for
ontology construction don't allow this,
but there are others that
do. There
is certainly no universal semantic
consideration, even in any strict
notion of
semantics, that would require that there be
two separate items here.
As far as I can tell, the Wikidata formalism is not one that would
disallow
offices being classes. As far as I can tell,
the rules for
constructing the
> Wikidata ontology don't disallow it either.
>
> Peter F. Patel-Schneider
> Nuance Communications
>
> _______________________________________________
> Wikidata mailing list
> Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
>
https://lists.wikimedia.org/mailman/listinfo/wikidata
>
> _______________________________________________
> Wikidata mailing list
> Wikidata(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikidata
>
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata