[Wikidata] Re: State of the (Wiki)data

Dear all, Thanks, Romaine, for this detailed and careful analysis of the situation. I think much of this is spot-on. I think one of the main insights here is that we need more uniformity. Wikidata in many places is still used like some exotic "structured" format for entering plain texts, whic

Re: [Wikidata] An answer to Lydia Pintscher regarding its considerations on Wikidata and CC-0

Dear Mathieu, Your post demands my response since I was there when CC0 was first chosen (i.e., in the April meeting). I won't discuss your other claims here -- the discussions on the Wikidata list are already doing this, and I agree with Lydia that no shouting is necessary here. Nevertheless

[Wikidata] SPARQL service: "too many requests"

Dear SPARQL team, in SQID, I now frequently see WDQS responses of type 429 when trying to load a page (doing this will usually issue a few dozen queries for larger pages). How many SPARQL queries are users allowed to ask in a certain time and how should tools behave when they hit this limit?

Re: [Wikidata] use of wdq and wqd create-a-query interface

On 20.10.2016 21:47, Stas Malyshev wrote: Hi! Jan, my Listeria bot currently manages ~13K lists on various WMF wikis. I just changed my update bot to collect all the queries that are used for those lists. It will take a day or so to collect them, then I'll forward them to you. Should be a good

Re: [Wikidata] Browsing concepts and entities

On 08.06.2016 13:34, Satya Gadepalli wrote: I want to look up concepts and entities by their name even if it contains typos or omissions in wiki data. Can I do this using Wikidata-Toolkit? No, there is no error-tolerant string matching function in there. If no other tool can help you, Wikidat

Re: [Wikidata] Accessing qualifier-specific data

On 19.05.2016 14:51, Markus Krötzsch wrote: Here is a simple SPARQL query to get population numbers from (any time in) 2015 of (arbitrary types of) entities, limited to 100 results: SELECT ?entity ?entityLabel ?population ?time WHERE { ?entity p:P1082 ?statement . ?statement ps:P1082

Re: [Wikidata] Accessing qualifier-specific data

Here is a simple SPARQL query to get population numbers from (any time in) 2015 of (arbitrary types of) entities, limited to 100 results: SELECT ?entity ?entityLabel ?population ?time WHERE { ?entity p:P1082 ?statement . ?statement ps:P1082 ?population . ?statement pq:P58

Re: [Wikidata] next round of the ArticlePlaceholder rollout

On 18.05.2016 21:42, Lydia Pintscher wrote: On Wed, May 18, 2016 at 6:54 PM Gerard Meijssen mailto:gerard.meijs...@gmail.com>> wrote: Hoi, When we already know what those properties are, we do not need to use SparQL we can use the result show the labels in their language. It is t

Re: [Wikidata] Wikimedia Blog post: "TED is partnering with the Wikimedia community..."

On 22.04.2016 18:41, Pine W wrote: Good news blog post: https://blog.wikimedia.org/2016/04/22/ted-wikimedia-collaboration/ Interesting. I just checked, and, lo and behold!, we really have TED talk information in Wikidata :-) http://tools.wmflabs.org/sqid/#/view?id=Q23058816 The page shows g

Re: [Wikidata] SPARQL service timeouts

On 19.04.2016 11:33, Addshore wrote: Also per https://phabricator.wikimedia.org/T126730 and https://gerrit.wikimedia.org/r/#/c/274864/8 requests to the query service are now cached for 60 seconds. I expect this will include error results from timeouts so retrying a request within the same 60 seco

Re: [Wikidata] SPARQL service timeouts

On 19.04.2016 11:05, Addshore wrote: In the case we are discussing here the truncated JSON is caused by blaze graph deciding it has been sending data for too long and then stopping (as I understand). Thus you will only see a spike on the graph for the amount of data actually sent from the server,

Re: [Wikidata] playing with Wikidata in BigQuery

On 12.03.2016 07:21, Stas Malyshev wrote: Something I need to figure out now: How to navigate the tree of sub-classes. Probably I'll create a 'convolution table', but maybe there's something out there I can use? This tree is huge :) And it may be also a bit weird. I can't remember from t

Re: [Wikidata] Status and ETA External ID conversion

t usage in Wikidata. Markus On 05.03.2016 17:15, Markus Krötzsch wrote: Hi, I agree with Egon that the uniqueness requirement is rather weird. What it means is that a thing is only considered an "identifier" if it points to a database that uses a similar granularity for modelling the world

Re: [Wikidata] Status and ETA External ID conversion

Hi, I agree with Egon that the uniqueness requirement is rather weird. What it means is that a thing is only considered an "identifier" if it points to a database that uses a similar granularity for modelling the world as Wikidata. If the external database is more fine-grained than Wikidata (

Re: [Wikidata] Status and ETA External ID conversion

On 05.03.2016 14:45, Lydia Pintscher wrote: On Sat, Mar 5, 2016 at 1:28 PM Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: Thanks, Katie. I see that the external ID datatype does not work as planed. At least I thought the original idea was to clean up the UI by

Re: [Wikidata] Status and ETA External ID conversion

n Sat, Mar 5, 2016 at 11:14 AM, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: Hi, I noticed that many id properties still use the string datatype (including extremely frequent ids like https://www.wikidata.org/wiki/Property:P213 and https://www.wikida

[Wikidata] Status and ETA External ID conversion

Hi, I noticed that many id properties still use the string datatype (including extremely frequent ids like https://www.wikidata.org/wiki/Property:P213 and https://www.wikidata.org/wiki/Property:P227). Why is the conversion so slow, and when is it supposed to be completed? Cheers, Markus _

Re: [Wikidata] SPARQL returns bnodes for some items

On 26.02.2016 14:25, Paul Houle wrote: You're not really supposed to use a named blank node as if it had a specific meaning. The name of a bnode never indicates a specific meaning. It is only used to mark multiple occurrences of the same bnode in some syntactic formats (such as RDF serialisat

Re: [Wikidata] SPARQL returns bnodes for some items

On 26.02.2016 13:32, James Heald wrote: These are used as placeholders for the meta-values "unknown value" and "no value" aren't they ? Oh, right! I had not considered it to be possible that any subclass of statement would use "unknown value". All classes could at least be subclasses of "Enti

Re: [Wikidata] from Freebase to Wikidata: the great migration

On 23.02.2016 16:30, Tom Morris wrote: ... Or the paper might be off. Addressing the flaws in the paper would require a full paper in its own right. Criticising papers is good academic practice. Doing so without factual support, however, is not. You may be right, but you should try to produ

Re: [Wikidata] from Freebase to Wikidata: the great migration

On 22.02.2016 18:28, Tom Morris wrote: On Sun, Feb 21, 2016 at 4:25 PM, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: On 21.02.2016 20 :37, Tom Morris wrote: On Sun, Feb 21, 2016 at 11:41 AM, Markus Krötzsch mailto:mar...@semantic-mediawi

Re: [Wikidata] from Freebase to Wikidata: the great migration

On 21.02.2016 20:37, Tom Morris wrote: On Sun, Feb 21, 2016 at 11:41 AM, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: On 18.02.2016 15:59, Lydia Pintscher wrote: Thomas, Denny, Sebastian, Thomas, and I have published a paper which was accept

Re: [Wikidata] from Freebase to Wikidata: the great migration

On 18.02.2016 15:59, Lydia Pintscher wrote: Hey everyone :) Thomas, Denny, Sebastian, Thomas, and I have published a paper which was accepted for the industry track at WWW 2016. It covers the migration from Freebase to Wikidata. You can now read it here: http://research.google.com/pubs/archive/4

Re: [Wikidata] from Freebase to Wikidata: the great migration

On 21.02.2016 16:00, Gerard Meijssen wrote: Hoi, I add statements of the primary sources tool in preference to add them myself (Primary Sources takes more time). I am still of the strongest opinion that given the extremely disappointing number of added statements the Primary Sources tool is a fa

[Wikidata] Undoing merges (bibliographic articles are not humans)

Hi all, What is the correct process to undo merges? There are three cases where a bibliographical article (in Wikisource) has been accidentally merged with the human the article is about: http://www.wikidata.org/entity/Q85393 http://www.wikidata.org/entity/Q312607 http://www.wikidata.org/enti

Re: [Wikidata] SPARQL endpoint caching

On 17.02.2016 10:34, Magnus Manske wrote: On Wed, Feb 17, 2016 at 7:16 AM Stas Malyshev mailto:smalys...@wikimedia.org>> wrote: Well, again the problem is that one use case that I think absolutely needs caching - namely, exporting data to graphs, maps, etc. deployed on wiki pages

Re: [Wikidata] SPARQL endpoint caching

On 17.02.2016 09:54, Katie Filbert wrote: ... I think it would be nice if having a graph with query on a page does not too much adversely affect the time it takes to save a page. (e.g. if running the query takes 20 seconds..., and instead reuse cached query results) And not have such usage kil

Re: [Wikidata] SPARQL endpoint caching

On 17.02.2016 08:16, Stas Malyshev wrote: Hi! (2) Shouldn't BlazeGraph do the caching (too)? It knows how much a query costs to re-run and it could even know if a query is affected by a data BlazeGraph does a lot of caching, but it's limited by the memory and it AFAIK does not do whole query

Re: [Wikidata] SPARQL endpoint caching

Hi, some random comments: (1) Are there any concrete cases of applications that need "super-up-to-date" results (where 120 sec is too old)? I do not currently run or foresee to run any such application. Moreover, I think that you have to allow for at least 60sec for an update to make it into

Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim, I think SERVICE queries should be working, but maybe Stas knows more about this. Even if they are disabled, this should not result in some message rather than in a NullPointerException. Looks like a bug. Markus On 16.02.2016 13:56, Neubert, Joachim wrote: Hi Markus, Great that

Re: [Wikidata] Wikidata Propbrowse

On 15.02.2016 11:52, Hay (Husky) wrote: On Mon, Feb 15, 2016 at 10:56 AM, André Costa wrote: Would it be possible to set the language used to search with? Whilst I most often use English on Wikidata I'm sure a lot of people don't. Not yet. The query takes quite a while, so it's done in realtim

Re: [Wikidata] Wikidata Propbrowse

On 14.02.2016 16:04, Hay (Husky) wrote: On Sun, Feb 14, 2016 at 3:53 PM, Jane Darnell wrote: Now I suddenly understand why we should have "properties for properties" so we can categorize these things. It would be nice to have a list of "authority control" properties and also the number of tim

Re: [Wikidata] Wikidata Propbrowse

Very nice. Showing the shortened property classifications under "use" is a very good idea! Markus On 14.02.2016 15:11, Jane Darnell wrote: Wow Hay, this is super useful On Sun, Feb 14, 2016 at 8:50 AM, Hay (Husky) mailto:hus...@gmail.com>> wrote: Awesome, thanks! :) -- Hay On S

Re: [Wikidata] SPARQL CONSTRUCT results truncated

On 12.02.2016 10:01, Osma Suominen wrote: 12.02.2016, 10:43, Markus Krötzsch wrote: Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent lo

Re: [Wikidata] SPARQL CONSTRUCT results truncated

On 12.02.2016 00:04, Stas Malyshev wrote: Hi! We basically have two choices: either we offer a limited interface that only allows for a narrow range of queries to be run at all. Or we offer a very general interface that can run arbitrary queries, but we impose limits on time and memory consumpt

Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim, Stas would be the right person to discuss service parameters and the possible setup of more servers with other parameters. He is part of the team at WMF who is in charge of the SPARQL ops. You note that "it isn’t always obvious what is right and what the limitations of a tool are

Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim, I think the problem is not to answer your query in 5min or so (Wikidata Toolkit on my laptop takes 27min without a database, by simply parsing the whole data file, so any database that already has the data should be much faster). The bigger issue is that you would have to configure

Re: [Wikidata] SPARQL CONSTRUCT results truncated

On 11.02.2016 15:01, Gerard Meijssen wrote: Hoi, What I hear is that the intentions were wrong in that you did not anticipate people to get actual meaningful requests out of it. When you state "we have two choices", you imply that it is my choice as well. It is not. The answer that I am looking

Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim, Here is a short program that solves your problem: https://github.com/Wikidata/Wikidata-Toolkit-Examples/blob/master/src/examples/DataExtractionProcessor.java It is in Java, so, you need that (and Maven) to run it, but that's the only technical challenge ;-). You can run the program

[Wikidata] Wikidata Toolkit 0.6.0 released

Hi all, I am happy to announce the release of Wikidata Toolkit 0.6.0 [1], the Java library for programming with Wikidata and Wikibase. The most prominent new feature of this release is improved support for writing bots (full support for maxlag and edit throttling, simpler code through conven

Re: [Wikidata] upcoming deployments/features

ndards. Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schub...@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: mor...@schubotz.de -Ursprüngliche Nachricht- Von: Mark

Re: [Wikidata] How to reach the wikipedia abstract propert?

Hi, For the record, I have heard a similar question recently. Maybe we could actually offer the abstracts as a service or otherwise "virtual" property that is simply added to the query result at the end. With the API Finn mentions (I did not know this, thanks!), it seems that this is not so h

Re: [Wikidata] upcoming deployments/features

a lot of developers, and yet ...). Markus On Wed, Feb 3, 2016 at 12:06 PM, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: For a consumer, the main practical questions would be: (1) What subset of LaTeX exactly do you need to support to display the math exp

Re: [Wikidata] upcoming deployments/features

other people's hands. Cheers, Markus Am 03.02.2016 um 14:31 schrieb Markus Krötzsch: Hi Moritz, I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that

Re: [Wikidata] upcoming deployments/features

On 03.02.2016 14:38, Daniel Kinzler wrote: Am 03.02.2016 um 14:31 schrieb Markus Krötzsch: Hi Moritz, I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was c

[Wikidata] SPARQL service slow?

Hi, is it me or is the SPARQL service very slow right now? Thanks, Markus ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] upcoming deployments/features

el.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schub...@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: mor...@schubotz.de -Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org] Gesendet: Mittwoch, 3. Februar 2016 12:06 An: Discussion list for the W

Re: [Wikidata] upcoming deployments/features

er on the list. Moritz On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher mailto:lydia.pintsc...@wikimedia.de>> wrote: On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote:

Re: [Wikidata] upcoming deployments/features

On 02.02.2016 23:31, Stas Malyshev wrote: Hi! Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though. Weird, does work for me incognito but not when logged in. The datatype

Re: [Wikidata] weekly summary #194

On 02.02.2016 02:07, Michael Karpeles wrote: Well, https://angryloki.github.io/wikidata-graph-builder will change my life, this is amazing. Thank you AngryLoki and all the hundreds of layers of contributors which lead to a tool like this. Also Lydia et al, thanks for the hard work in keeping thes

Re: [Wikidata] upcoming deployments/features

On 01.02.2016 17:14, Lydia Pintscher wrote: Hey folks :) I just sat down with Katie to plan the next important feature deployments that are coming up this month. Here is the plan: * new datatype for mathematical expressions: We'll get it live on test.wikidata.org tomor

Re: [Wikidata] Miga Classes and Properties Browser

On 16.12.2015 11:10, Gerard Meijssen wrote: Hoi, In the WDQ database all the data on P and Q values exist. It is stable and it has proven itself over the last years as flexible and very fast. Why build another database that is specific to one goal when another database already exists that largely

Re: [Wikidata] Miga Classes and Properties Browser

n via the Web API) Thanks, Markus On 15 December 2015 at 22:54, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: Hi, Something to be noted here is that initial loading is quite a bit slower than it used to be, since there are a lot more classes now. We

Re: [Wikidata] Miga Classes and Properties Browser

Hi, Something to be noted here is that initial loading is quite a bit slower than it used to be, since there are a lot more classes now. We are looking into options of making this faster, but this might need a full rewrite to become really fast. The good thing is that loading only has to happ

Re: [Wikidata] Query Service Examples

Thanks, nice. Two comments: * Activating the tag cloud in the UI was not very intuitive to me. I thought this was the search button or something. * The tag cloud pop-up is half off-screen for me, and I cannot move it to be fully visible (Firefox, Linux). Cheers, Markus On 10.12.2015 17:12,

Re: [Wikidata] [Wikimedia-l] Quality issues

P.S. Meanwhile, your efforts in other channels are already leading some people to vandalise Wikidata just to make a point [1]. Markus [1] http://forums.theregister.co.uk/forum/1/2015/12/08/wikidata_special_report/ On 09.12.2015 11:32, Markus Krötzsch wrote: On 08.12.2015 00:02, Andreas

Re: [Wikidata] [Wikimedia-l] Quality issues

On 08.12.2015 00:02, Andreas Kolbe wrote: Hi Markus, ... Apologies for the late reply. While you indicated that you had crossposted this reply to Wikimedia-l, it didn't turn up in my inbox. I only saw it today, after Atlasowa pointed it out on the Signpost op-ed's talk page.[1] Yes, we hav

Re: [Wikidata] Wikidata Analyst, a tool to comprehensively analyze quality of Wikidata

Hi Amir, Very nice, thanks! I like the general approach of having a stand-alone tool for analysing the data, and maybe pointing you to issues. Like a dashboard for Wikidata editors. What backend technology are you using to produce these results? Is this live data or dumped data? One could al

Re: [Wikidata] REST API for Wikidata

On 02.12.2015 23:17, Martynas Jusevičius wrote: JSON-LD does add complexity over plain JSON -- because it also can be interpreted as RDF. And that makes all the difference. The importance of this distinction cannot be overstated. If one views some custom JSON and JSON-LD (and by extension, RDF)

Re: [Wikidata] REST API for Wikidata

On 02.12.2015 12:07, Bene* wrote: I agree it would be cool to use some standard format as an api output! I am usually all for Web standards and so on, but I have also seen with the Wikidata-to-RDF mapping work that it really is a lot of effort to do such a mapping properly. We already have tw

Re: [Wikidata] [Wikimedia-l] Quality issues

[I continue cross-posting for this reply, but it would make sense to return the thread to the Wikidata list where it started, so as to avoid partial discussions happening in many places.] Andreas, On 27.11.2015 12:08, Andreas Kolbe wrote: Gerard, (I should note that my reply has nothing to

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

On 28.11.2015 16:51, Federico Leva (Nemo) 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 h

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

such superclasses is another matter of course ...). Markus 2015-11-27 16:41 GMT+01:00 Markus Krötzsch mailto:mar...@semantic-mediawiki.org>>: Hi James, I would immediately agree to the following measures to alleviate your problem: (1) If some instance-of statement

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

Hi James, I would immediately agree to the following measures to alleviate your problem: (1) If some instance-of statements are historic (i.e., no longer valid), then one should make the current ones "preferred" and leave the historic ones "normal", just like for, e.g., population numbers. T

Re: [Wikidata] Odd results from wdqs

need some extra memory, but the data you get in the end should not be much bigger than the original string, or should it? Markus On Fri, Nov 27, 2015 at 2:12 PM Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: On 25.11.2015 16:05, Lydia Pintscher wrote: > On Mon,

Re: [Wikidata] Odd results from wdqs

On 25.11.2015 16:05, Lydia Pintscher wrote: On Mon, Nov 23, 2015 at 10:54 PM, Magnus Manske wrote: Well, my import code chokes on the last two JSON dumps (16th and 23rd). As it fails about half an hour or so in, debugging is ... inefficient. Unless there is something that has changed with the d

Re: [Wikidata] Some questions on dates

On 23.11.2015 17:55, David Lowe wrote: I'm working at the moment finding places of birth for photographers who have birthdates but lack locations (my query is below). Ultimately I'll be comparing WD's photographer info to my own database of photographer biographies. This leads me to a few questio

Re: [Wikidata] [Wiki-research-l] Quality issues

On 21.11.2015 12:21, Jane Darnell wrote: +1 I think many Wikipedians are control freaks who like to think their articles are the endpoint in any internet search on their article subjects. We really need to suppress the idea that the data they have curated so painstakingly over the years is less v

Re: [Wikidata] [Wiki-research-l] Quality issues

On 20.11.2015 09:18, Federico Leva (Nemo) wrote: Gerard Meijssen, 20/11/2015 08:18: At this moment there are already those at Wikidata that argue not to bother about Wikipedia quality because in their view, Wikipedians do not care about its own quality. And some wikipedians say the same of Wik

Re: [Wikidata] WDQS updates have stopped

On 19.11.2015 10:40, Gerard Meijssen wrote: Hoi, Because once it is a requirement and not a recommendation, it will be impossible to reverse this. The insidious creep of more rules and requirements will make Wikidata increasingly less of a wiki. Arguably most of the edits done by bot are of a hig

Re: [Wikidata] WDQS updates have stopped

On 18.11.2015 19:40, Federico Leva (Nemo) wrote: Andra Waagmeester, 18/11/2015 19:03: How do you do add "hunderds (if not thousands)" items per minute? Usually 1) concurrency, 2) low latency. In fact, it is not hard to get this. I guess Andra is getting speeds of 20-30 items because their b

Re: [Wikidata] "Implementing" OWL RL in SPARQL (Was: qwery.me - simpler queries for wikidata)

On 12.11.2015 22:09, Peter F. Patel-Schneider wrote: On 11/12/2015 09:10 AM, Markus Krötzsch wrote: [...] On the other hand, it is entirely possible to implement correct OWL QL (note: *QL* not *RL*) reasoning in SPARQL without even using "rules" that need any recursive evaluation

[Wikidata] "Implementing" OWL RL in SPARQL (Was: qwery.me - simpler queries for wikidata)

On 12.11.2015 16:30, Paul Houle wrote: This is really great stuff that gets to the heart of the matter. There is a horrible misconception that SPARQL is complex. People often show you queries that make your head spin, but it is astonishing how really simple they are. Here are a set of SPARQL

Re: [Wikidata] Data model explanation and protection

On 11.11.2015 11:33, Thomas Douillard wrote: There is a proposal for some kind of class disjointness : https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#subclass this is here for a while now, maybe a few more supporters would speed up the process :) Interesting. This looks like a

Re: [Wikidata] qwery.me - simpler queries for wikidata

Nice! In fact, I am fine with writing SPARQL, but I still find this very useful. Looking up entity ids can be cumbersome, and your automcompletion on labels is extremely useful there. Markus On 11.11.2015 01:09, Paul Sonnentag wrote: Hey, A week ago I started working on a project which trie

Re: [Wikidata] Data model explanation and protection

On 29.10.2015 05:41, Benjamin Good wrote: For what its worth, I tend to agree with Peter here. It makes sense to me to add constraints akin to 'disjoint with' at the class level. +1 for having this. This does not preclude to have an additional mechanism on the instance level if needed to augm

Re: [Wikidata] Blazegraph

On 28.10.2015 12:24, Kingsley Idehen wrote: On 10/27/15 4:24 PM, Markus Krötzsch wrote: Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely

Re: [Wikidata] Blazegraph

On 28.10.2015 10:11, Dimitris Kontokostas wrote: ... Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of

Re: [Wikidata] Blazegraph

On 27.10.2015 15:34, Paul Houle wrote: One thing I really liked about Kasabi was that it had a simple interface for people to enter queries and share them with people. The "Information Workbench" from fluidOps does something similar although I never seen it open to the public. A database of que

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 25.10.2015 02:18, Kingsley Idehen wrote: On 10/24/15 10:51 AM, Markus Krötzsch wrote: On 24.10.2015 12:29, Martynas Jusevičius wrote: I don't see how cycle queries can be a requirement for SPARQL engines if they are not part of SPARQL spec? The closest thing you have is property paths.

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 24.10.2015 12:29, Martynas Jusevičius wrote: I don't see how cycle queries can be a requirement for SPARQL engines if they are not part of SPARQL spec? The closest thing you have is property paths. We were talking about *cyclic data* not cyclic queries (which you can also create easily usin

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 24.10.2015 09:36, James Heald wrote: On 24/10/2015 00:50, Stas Malyshev wrote: Hi! least one Wikipedia) are considered to refer to equivalent classes on Wikidata, which could be expressed by a small subclass-of cycle. For We can do it, but I'd rather we didn't. The reason is that it would

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 23.10.2015 20:19, Stas Malyshev wrote: Hi! I am happy to announce a new tool [1], written by Serge Stratan, which allows you to browse the taxonomy (subclass of & instance of relations) between Wikidata's most important class items. For example, here is the Wikidata taxon

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 23.10.2015 09:12, Markus Krötzsch wrote: On 22.10.2015 21:49, Benjamin Good wrote: I am having the same kinds of 500 problems. Bitbucket is generally suffering today: http://status.bitbucket.org Indeed, they had a site-wide issue. Seems to be fixed now. I was rejoicing too early here

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 23.10.2015 11:16, Gerard Meijssen wrote: Hoi, The problem with tools like this is that they get a moment attention. Particularly when they are stand alone, not integrated, they will lose interest. Problems, problems, ... Would it be an option to host this tool on Labs? Yes, this is plan

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

On 22.10.2015 21:49, Benjamin Good wrote: I am having the same kinds of 500 problems. Bitbucket is generally suffering today: http://status.bitbucket.org Indeed, they had a site-wide issue. Seems to be fixed now. Markus On Thu, Oct 22, 2015 at 12:27 PM, Markus Kroetzsch mailto:markus.kroet

Re: [Wikidata] need help in running Wikidata-Toolkit-0.5.0 examples

[Maybe let's move this to wikidata-tech -- including the Wikidata discussion list here for the last time; please remove it in your reply] Dear Satya, Both issues you encountered seem to be caused by how you run the examples. It seems that the project is not configured/compiled properly yet.

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

On 19.10.2015 04:44, Emw wrote: ... The phrase "is a" is in no way mutually exclusive with "subclass of". "Is a" is ambiguous -- it can mean the subject is either a class or an instance. In other words, "is a" can mean either /instance of/ (P31) or /subclass of/ (P279). Indeed. Alas, some lan

Re: [Wikidata] Announcing wdq command line client

Hi Jakob, Very handy, thanks. Markus On 07.10.2015 14:04, Jakob Voß wrote: Hi, Based on a script by Marius Hoch (https://github.com/mariushoch/asparagus) I created a command line client to access Wikidata Query Service. The current release 0.2.0 includes the following features: * adding of

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

On 01.10.2015 00:13, Daniel Kinzler wrote: Am 30.09.2015 um 23:38 schrieb Peter F. Patel-Schneider: I would argue that inference-making bots should be considered only as a stop-gap measure, and that a different mechanism should be considered for making inferences in Wikidata. I am not arguing f

Re: [Wikidata] Duplicate identifiers (redirects & non-redirects)

On 01.10.2015 00:58, Ricordisamoa wrote: I think Tom is referring to external identifiers such as MusicBrainz artist ID etc. and whether Wikidata items should show all of them or 'preferred' ones only as we did for VIAF redirects

Re: [Wikidata] Importing Freebase (Was: next Wikidata office hour)

is wasted and it is much more effective for me to add new data than work on data that is already in the primary sources tool. Thanks, GerardM On 28 September 2015 at 16:52, Markus Krötzsch mailto:mar...@semantic-mediawiki.org>> wrote: Hi Gerard, hi all, The key misunde

Re: [Wikidata] Importing Freebase (Was: next Wikidata office hour)

Hi Thad, thanks for your support. I think this can be really useful. Now just to clarify: I am not developing or maintaining the Primary Sources tool, I just want to see more Freebase data being migrated :-) I think making the mapping more complete is clearly necessary and valuable, but maybe

[Wikidata] Importing Freebase (Was: next Wikidata office hour)

est bet. Specific properties were much better maintained than others -- identify those that meet the bar for wholesale import and leave the rest to the primary sources tool. On Thu, Sep 24, 2015 at 4:03 PM Markus Krötzsch mailto:mar...@semantic-mediawiki.org&

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

On 28.09.2015 13:31, Luca Martinelli wrote: 2015-09-28 11:16 GMT+02:00 Markus Krötzsch : If this is the case, then maybe it should just be kept as an intentionally broad property that captures what we now find in the Wikipedias. +1, the more broad the application of certain property is, the

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

Hi, Important discussion (but please don't get angry over such things -- some emails sounded a bit rough to my taste if I may say so :-). Property definitions are an important issue, and ours are too vague in general. However, some properties need to be quite broad to be useful: they need so

Re: [Wikidata] next Wikidata office hour

On 24.09.2015 23:48, James Heald wrote: Has anybody actually done an assessment on Freebase and its reliability? Is it *really* too unreliable to import wholesale? From experience with the Primary Sources tool proposals, the quality is mixed. Some things it proposes are really very valuable,

Re: [Wikidata] Wikidata Live RDF?

On 09.09.2015 08:30, Stas Malyshev wrote: Hi! Now that the SPARQL endpoint is "official", will the life RDF data (which you get, e.g, via Special:EntityData) also be switched to show the content using in SPARQL? Since this is already implemented, I guess I think it might be a good idea. We ha

Re: [Wikidata] Announcing the release of the Wikidata Query Service

Good morning :-) On 09.09.2015 00:45, Stas Malyshev wrote: Hi! P.S. I am not convinced yet of this non-standard extension of SPARQL to fetch labels. Its behaviour based on the variables given in SELECT seems You don't have to use variables in SELECT, it's just a shortcut. What I meant with

Re: [Wikidata] Announcing the release of the Wikidata Query Service

On 09.09.2015 00:13, Stas Malyshev wrote: Hi! Anyone an idea why this query has a trouble when I add the OPTIONAL keyword? *http://tinyurl.com/pgsujp2* Doesn't look much harder than the queries in the examples. It's not because it's harder. It's because ?head can be unbound, and you can not

  1   2   >