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(a)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(a)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(a)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(a)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(a)gmail.com
:BaseKB -- Query Freebase Data With SPARQL
http://basekb.com/gold/
Legal Entity Identifier Lookup
https://legalentityidentifier.info/lei/lookup/
<http://legalentityidentifier.info/lei/lookup/>
Join our Data Lakes group on LinkedIn
https://www.linkedin.com/grp/home?gid=8267275