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@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_paper_11.pdf
>
> 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@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@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
>     https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
>
> _______________________________________________
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>

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