Hi all,
We have prepared a new browser for Wikidata Properties:
http://tools.wmflabs.org/wikidata-exports/miga/
It is based on Miga data browser [1]. This means it only works in Google
Chrome/Chromium, Opera, Safari, and the Android Browser but not in
Internet Explorer, Firefox, and Rekonq.
You can browse properties by datatype or usage numbers, and also find
related properties for every property (using my own custom notion of
"relatedness" based on relative co-occurrence and overall prevalence).
When filtering by usage numbers, you sometimes see only very coarse
filters, but you can always apply the same filter again to get more fine
grained steps. You can also edit the URL in the browser to modify
filters if you cannot find the right one in the UI.
This is still experimental. The data is based on the dump of 26 May. The
data files for Miga were created using Wikidata Toolkit [2]; I will
commit the specific code in due course. Feedback is welcome.
Cheers,
Markus
[1] http://migadv.com/
[2] https://www.mediawiki.org/wiki/Wikidata_Toolkit
I'm still talking of the model I proposed in my first post in this thread.
I did give an advantage : you can really simply query the type of units
used by a country to class his administrative units, like <Region>,
<Departement> (as two items) for France with just simple in one request of
the future simple query module : just retrieve the instances of the class
<French type of administrative units>. This model also apply to any country
administrative territorial division.
I think <French type of administrative units> is the "auxiliary item"
markus did mention. We can define precisely what it is becaus this class
<French type of administrative units> regroups the types used by france to
class cities, departments ... so clearly if we talk of "Paris", there is
several possibility, like the region of Paris, the City of Paris ... <The
city of Paris> item is clearly the only one who is clearly defined by
french law, hence it is an instance of the class <French ville>, who in
turn is an instance of <French type of administrative units>.
This seems to me a useful model, who can generalise easily to class things
like "Urban units", who are used for statistical purpose and are defined by
national statistical organism in each country, such as INSEE in france
Then we could also have a <Urban unit> class in Wikidata, but this is
ambiguous.
This class could have a subclass <Urban unit as defined by INSEE>, with
instances such as <Parisian urban unit>, for hich it gives statistical
information. <Urban unit as defined by INSEE> in turn may be a subclass of
<any geographical unit defined by INSEE>. Then if you want INSEE
geographical units, you query all instances of both <Urban unit> and <any
geographical unit defined by INSEE>.
But now let's say you want to find the definition of urban unit by the
INSEE itself, not the instances. One way to do that would be to look at the
subclass tree of <any geographical unit defined by INSEE> or the one of
<Urban unit>, or compute the intersection of both trees.
One alternative, using metamodelling this time, would be to have a class
regrouping all definitions of statistical units used by INSEE. Those
definitions identify to some class we already have, such as <Urban unit as
defined by INSEE> identifies to the definition of urban unit by INSEE. Then
the class of all definitions used by INSEE would identify to the class of
all classes with a name <... unit defined by INSEE>. I propose to create
the item <any type of unit defined by INSEE> ; with <Urban unit as defined
by INSEE> an instance of it (actually I might have already have done it /o\)
This is an (non mutually exclusive, more complementary) alternative to just
class administrative units instances. In a way, this is just identifying
(reifying) a classification system and putting an ''instance of'' <this
item> statements to its classes.
I think this is interesting in Wikidata as we actually are using a lot of
different classification system, having a clear and practicable pattern
like this one, using just a few tools like reasonator, is useful.
For example if I want to compute the subclass tree of statistical units,
but only the classes used by INSEE, I can compute the subclass tree of the
<statistical geographical unit> class but filtering only the instances of
<any type of unit defined by INSEE>, instead of computing a tree
intersection.
This kind of patterns occurs also for example in biological taxonomy. They
use classes such as "Genera", "taxon", "clade". Imo any instance of taxon
can be seen as a class of living organisms. Then Taxon is a class of class,
just as <any type of unit defined by INSEE> can be seen by a class of
class. <Clade> is a subclass of taxon because any clade is a taxon. So
clade is also a class of class.
This makes this pattern actually already used, and studied in the world of
semantic web. As it's simple and can be found in a lot of domains, I think
we should use it in Wikidata.
2014-06-11 11:51 GMT+02:00 Gerard Meijssen <gerard.meijssen(a)gmail.com>:
Hoi,
> You lost me. What have classes to do with this?
>
> The system is flexible and you assume that there are special cases... Name
> one and it can be fit in.
> Thanks,
> GerardM
>
>
> On 11 June 2014 11:48, Thomas Douillard <thomas.douillard(a)gmail.com>
> wrote:
>
>> There is always special cases that needs special treatments, inference is
>> done again and again, there is no point to recompute everything with an
>> algorithm or a query with hard coded exceptions when we have a simple and
>> regular system who can handle and put the exceptions in the datas.
>>
>> Class of classes is such a system. I'll quote the python programming
>> language motto here "explicit is better than implicit", which is not really
>> different from "avoid redundances at all cost is not always a good thing".
>>
>> The same reason we have classes in the first time, can also apply to
>> classes of classes. Some class membership can be inferred by a query, I
>> don't think it's always a bad idea to state the membership explicitely in
>> all cases.
>>
>>
>> 2014-06-11 11:21 GMT+02:00 Gerard Meijssen <gerard.meijssen(a)gmail.com>:
>>
>> Hoi,
>>> A bot run by Amir has remedied many of the issues that resulted from an
>>> import of data for the United States. The fix was to only point to one
>>> level up and not have a reference to the state from every location. It is
>>> implicitly there.. in the final analysis we do not need to know in what
>>> country something is as it can be inferred.
>>>
>>> This system assumes that we build the upper layers as is relevant to a
>>> specific country,. So yes it is usable for any country, type of
>>> administrative or territorial entity including how for instance the Roman
>>> Catholic church does its thing.
>>> Thanks,
>>> Gerard
>>>
>>>
>>> On 11 June 2014 11:08, Thomas Douillard <thomas.douillard(a)gmail.com>
>>> wrote:
>>>
>>>> Hi, Gerard, I don't understand, As needed for what ?
>>>> In your example it is enough to retrieve all the territorial entities a
>>>> location is in.
>>>>
>>>> But let's say I want to get the administrative territorial organisation
>>>> of France (Wikipedias probably ), I mean like "france is divided in
>>>> regions, regions are divided in departments, and so on), for example, do we
>>>> have enough in your model ?
>>>>
>>>> I propose to add to the classes like <French Region> for example an
>>>> "instance of" claim that states <French Region> instance of <French
>>>> administrative division type> to reflect that in Wikidata.
>>>>
>>>> Then if I want to know how france is administratively divided, I query
>>>> all the instances in that class.
>>>>
>>>> This is a complement to <Pays de la Loire> instance of <French region>
>>>> for example.
>>>>
>>>>
>>>>
>>>> 2014-06-11 10:37 GMT+02:00 Gerard Meijssen <gerard.meijssen(a)gmail.com>:
>>>>
>>>> Hoi,
>>>>> Important to recognise is that there can be as many layers as are
>>>>> needed.. ie a roller coaster can be in a park, a park can be in a
>>>>> settlement, a settlement in a municipality, a municipality in a county, a
>>>>> county in a province, a province in a state and finally a state in a
>>>>> country (that is on a continent)...
>>>>>
>>>>> This is how it effectively is already in Wikidata for many "locations"
>>>>> Thanks,
>>>>> Gerard
>>>>>
>>>>>
>>>>> On 11 June 2014 09:48, Thomas Douillard <thomas.douillard(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi, I basically proposed a two layers model in extended discussions :
>>>>>> Administrative units | Administrative unit type | Administrative unit
>>>>>> classes by country
>>>>>> City Of London | City of the UK | Type of
>>>>>> administrative unit of the UK
>>>>>> Lorraine | French Region | Type of
>>>>>> administrative unit of France
>>>>>>
>>>>>> Where going one step left in the table reads ''instance of''. This
>>>>>> seem close to your ''helper item'' model.
>>>>>>
>>>>>>
>>>>>
Hey everyone,
Just thought I'd inform that I have changed the design of all three
Wikidata mailing lists (wikidata-l, wikidata-tech and wikidata-bugs) to a
new, more appealing design.
It is based off the one currently used on MediaWiki-l (with source publicly
available by Quim Gil) the changes being the Wikidata logo is used in place
of the Wikimedia one and there are links around to the other mailing lists.
Just a nice small design tweak which I think the community would appreciate
:) Any suggestions - poke me.
John Lewis
Hello,
I've noticed that there are a lot of script errors towards the bottom of
Wikidata:List of properties/Summary table
I suspect that this is caused by the same thing mentioned in this email:
https://www.mail-archive.com/wikidata-l@lists.wikimedia.org/msg02756.html
Is there anything that can be done about this at all? This is an incredibly
useful list and it's sad to only be able to see half of it. Should the page
just be split?
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Dear all,
I am happy to announce the second release of Wikidata Toolkit [1], the
Java library for programming with Wikidata and Wikibase. This release
fixes bugs and improves features of the first release (download, parse,
process Wikidata exports) and it adds new components for serializing
JSON and RDF exports for Wikidata. A separate announcement regarding the
RDF exports will be sent shortly.
Maven users can get the library directly from Maven Central (see [1]);
this is the preferred method of installation. There is also an
all-in-one JAR at github [2] and of course the sources [3].
Version 0.2.0 is still in alpha. For the next release, we will focus on
the following tasks:
* Faster loading of Wikibase dumps + support for the new JSON format
that will be used in the dumps soon
* Support for storing and querying data after loading it
* Initial steps towards storing data in a binary format after loading it
Feedback is welcome. Developers are also invited to contribute via github.
Cheers,
Markus
[1] https://www.mediawiki.org/wiki/Wikidata_Toolkit
[2] https://github.com/Wikidata/Wikidata-Toolkit/releases
(you'll also need to install the third party dependencies manually when
using this)
[3] https://github.com/Wikidata/Wikidata-Toolkit/
Hi everyone!
In the sources of Wikibase I see Ask library from which I conclude
that we will have awesome SMW-like queries. Am I right? What is the
status of query features and how will the queries look like when they
are ready?
-----
Yury Katkov
Hello,
I am reading the documentation of WikiData where I learned that new
properties could be suggested for discussion. But this means adding knew
properties to WikiData. However, is it possible to use existing RDF
vocabularies like the RDF implementation <http://www.rdaregistry.info/>
of RDA <http://www.loc.gov/aba/rda/> a cataloging norm based on the FRBR
<http://www.ifla.org/publications/functional-requirements-for-bibliographic-…>
conceptual model (Functional Requirements for Bibliographic Records)
(see also "What is FRBR? <http://www.loc.gov/cds/downloads/FRBR.PDF>") ?
Unless this could be considered like librarian stuff, the FRBR
conceptual model is an interresting way of expressing relations between
any work (book, music, movie...) and their authors because it makes a
distinction between the work ("20.000 lieues sous les mers", the novel
written by Jules Verne) and its manifestations (the publication of this
novel by Hetzel in Paris in 1871). FRBR suggest two more levels
"expression" (which I don't understood yet) and item (an explary of the
book). This model was used by the Bibliothèque Nationale de France (BNF)
for its web site data.bnf.fr, the open data portal of the BNF.
What I mean, is that I could ask for a new property in WikiData like
p:writerOf, but why not using rdaw:author (rdaw:
http://rdaregistry.info/Elements/w/) or rather than having a WikiData
property p:workTitle using rdaw:titleOfTheWork ?
Thanks,
--
Jean-Baptiste Pressac
Traitement et analyse de bases de données
Centre de Recherche Bretonne et Celtique
UMS 3554
20 rue Duquesne
CS 93837
29238 Brest cedex 3
tel : +33 (0)2 98 01 68 95
fax : +33 (0)2 98 01 63 93
Good morning,
Does anyone know if there has been a gadget developed that adds a link to the
tools section, or somewhere similar, from Wikipedia articles to their
corresponding Wikidata items. Such a gadget would make it significantly easier
to manually import data in Wikidata while reading Wikipedia casually.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Hello everyone,
Just a note that Wikiquote now has Phase 2 access. Some communities may
need help with Lua and the general implementation of Phase 2 so please help
as you can :)
John Lewis