Years ago I made somebody a classification into ten or so "subjects" that might correspond to the sections of a magazine:  movies,  music,  TV,  sports,  business,  etc.

The person who wound up in the most categories was not the Austrian polymath,  but Alyssa Milano who not only acts but dances and sings and is involved with charity and has a medical condition,  etc.

As also mentioned,  cities are also a source of trouble because there are lots of "places where X happens" or "places that contain Y" -- they might not do that in Georgia but they certainly do X and have Y in Atlanta so big cities get a pile of uninformative types.

The funny thing is that once you start building an actual application over some actual problem domain,  these problems mostly dry up and blow away -- unless it is (1) celebrity gossip,  (2)  Wikidata's service to Wikipedia,  or (3) building editing interfaces like the one for Wikidata,

There is a strong danger in (3) that you build CycL,a  platform to develop Cyc with ,and then Cyc and CycL coevolve to the point where they can't imagine throwing out Cyc and knocking out something simple with CycL -- at that point the software is programming you.


On Mon, Nov 30, 2015 at 3:46 AM, James Heald <j.heald@ucl.ac.uk> wrote:
Thanks Gerard, but which ones do you think could be qualifiers?  And qualifiers of what?

As a default position, I tend to be against hiding information in qualifiers when it is an actual fact about the item, because it makes the fact harder to extract and to use -- eg it's harder (and slower) to include in a recursive query.  So as I rule, I prefer to use qualifiers to indicate the sense in which something is true, or any limits on its truth, rather than as a place to store primary facts.

In terms of currency, all of the statuses have current relevance (though some may be more significant than others), apart from Q21457810.

But even for historical facts, it makes queries for those historical facts trickier if they can't be retrieved using the wdt:... form of properties -- or rather (in fact, worse) if the wdt:... query *appears* to work, and retrieves some values, but is in fact silently not returning all of them.

  -- James.




On 30/11/2015 04:40, Gerard Meijssen wrote:
Hoi,
Most of these could be / should be qualifiers. Several are historic and no
longer valid.
Thanks,
     GerardM

On 29 November 2015 at 23:42, James Heald <j.heald@ucl.ac.uk> wrote:

If we look at Glasgow,
      https://www.wikidata.org/wiki/Q4093

the values for P31 in question are:

     Q515       -- city
     Q15060255  -- council area
     Q7309443   -- registration county
     Q202435    -- lieutenancy area of Scotland
     Q21457810  -- Scottish district (1975 to 1996)

Each of those statuses is different and independent (even in a purely
Scottish context):  none of them implies any of the others, none of them is
implied by any of the others.

So, in this case, I don't see that "city of Scotland" would help at all.

   -- James.





On 29/11/2015 17:56, Joe Filceolaire wrote:

Why have instance of item and instance of superclass of that item?
If Glasgow is instance of : city of Scotland  and
City of Scotland is subclass of : city
Then we should not have Glasgow instance of : city

This principle should cut down a lot of these extra 'instances '

Joe

On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) <nemowiki@gmail.com>
wrote:

Gerard Meijssen, 28/11/2015 07:05:

A big city is what? A city with more than a given number of inhabitants?
If so it is redundant because it can be inferred.


Criteria might be defined by local law and/or require some
administrative act. That's how it works in Italy, for instance.

Nemo



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



--
Paul Houle

Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes

(607) 539 6254    paul.houle on Skype   ontology2@gmail.com

:BaseKB -- Query Freebase Data With SPARQL

Legal Entity Identifier Lookup

Join our Data Lakes group on LinkedIn