[Wikidata-l] LoCloud and Wikimedia
Have anyone heard about a LoCloud project in Europeana? Its about integration of Wikimedia services and content in a cloud service for local glam institutions. It seems like the project was started officially in March 2013. LoCloud is a cloud service for small and medium sized institutions. It seems like WLM will be part of this through work package 3, and then as a micro service (!) in a larger system based on SaaS. John ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] LoCloud and Wikimedia
There is a discussion on the cultural-partners list from 26th March 2013. John On Mon, Aug 26, 2013 at 9:47 AM, John Erling Blad jeb...@gmail.com wrote: Have anyone heard about a LoCloud project in Europeana? Its about integration of Wikimedia services and content in a cloud service for local glam institutions. It seems like the project was started officially in March 2013. LoCloud is a cloud service for small and medium sized institutions. It seems like WLM will be part of this through work package 3, and then as a micro service (!) in a larger system based on SaaS. John ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Cooperation between Wikidata and DBpedia and Wikipedia
Speaking from DBpedia (not on behalf), we have been always trying to find ways to contribute data back to wikipedia and If licencing is the only issue here I am sure we can make any necessary arrangements. imho the main scepticism so far was trust from the WIkipedia community to load data in bulk. However, there are datasets of very high quality in DBpedia that could be used for that purpose. Recently we are experimenting in an alternative where people can manually import single facts in Wikidata from the DBpedia resource interface. Here's a recent talk about this [1] on the tech list. Any comments on that are also welcome. Best, Dimitris [1] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-August/000189.html On Fri, Aug 23, 2013 at 6:18 PM, David Cuenca dacu...@gmail.com wrote: Hi, I will answer with questions with more questions... On Fri, Aug 23, 2013 at 10:58 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The questions are: - would we advance a lot when we adopt the DBpedia schema as it is? Which schema? All of them? Some? Article classification? Infobox extraction? Wikidata is going to be linked to the infoboxes in Wikipedia, so the priority is to support those needs, not to replicate any schema. - Would we be open to include substantially more data? Which data? All of it? What is the reliability? - When we adopt the schema, can we tinker with it to suit our needs? Again, could you please give some example of what to import and how should it be adapted? If the answers to these questions are yes, what is the point in procrastinating??? Do we have already all the datatypes that would be needed? Most of the properties that are missing is because of the lack of value or others. One other big thing of DBpedia is that it is connected to many external resources. This will make it possible to verify our data against these other sources. This is imho the more important thing to do with the time of our volunteers. Doing the things that have already been done is a waste of time. The thing is that if those resources already are in dbpedia, we can just use dbpedia as a bridge, that is how linked data is supposed to be... no need to replicate everything, but of course, if it is worth replicating, we can go through case by case. Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Dimitris Kontokostas Department of Computer Science, University of Leipzig Research Group: http://aksw.org Homepage:http://aksw.org/DimitrisKontokostas ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Cooperation between Wikidata and DBpedia and Wikipedia
Hoi, Two things to consider; the Wikipedia community and the Wikidata community are two separate entities. As far as I am concerned, Wikidata needs more data to get to the tipping point where it becomes useful to users. I am really vocal about both. The license has traditionally been a sticking point and the not invented here aspect of DBpedia is as well. You are effectively outside the Wikipedia community.. The other part is that the data of Wikidata is continually updated while DBpedia is not. So in my opinion the best thing that can happen is when DBpedia DOES update with Wikidata. The point is not to absorb it without thinking. What DBpedia has is a set of properties that work on the data that it has gleaned from the many Wikipedias. There is undoubtedly a lot of documentation on it and, it would be good when this is taken into consideration when accepting and proposing new properties for Wikidata. Obviously only the properties that are currently supported can be proposed at this time. I am quite willing to propose properties based on DBpedia (but so can you). With the properties in place, we can import data. We can import it from both DBpedia and from Wikipedia. Sanity checks are needed for both sources and as far as I am aware we do not have sanity checks at Wikidata. What we do have is the possibility to compare data with other sources and that is where the Wikidata community needs to grow and that is why we need much data in the first place in order to get into this. However, we can start building the tools to do this. I hope the DBpedia community can help us with that. Thanks, GerardM On 26 August 2013 09:16, Dimitris Kontokostas kontokos...@informatik.uni-leipzig.de wrote: Speaking from DBpedia (not on behalf), we have been always trying to find ways to contribute data back to wikipedia and If licencing is the only issue here I am sure we can make any necessary arrangements. imho the main scepticism so far was trust from the WIkipedia community to load data in bulk. However, there are datasets of very high quality in DBpedia that could be used for that purpose. Recently we are experimenting in an alternative where people can manually import single facts in Wikidata from the DBpedia resource interface. Here's a recent talk about this [1] on the tech list. Any comments on that are also welcome. Best, Dimitris [1] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-August/000189.html On Fri, Aug 23, 2013 at 6:18 PM, David Cuenca dacu...@gmail.com wrote: Hi, I will answer with questions with more questions... On Fri, Aug 23, 2013 at 10:58 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The questions are: - would we advance a lot when we adopt the DBpedia schema as it is? Which schema? All of them? Some? Article classification? Infobox extraction? Wikidata is going to be linked to the infoboxes in Wikipedia, so the priority is to support those needs, not to replicate any schema. - Would we be open to include substantially more data? Which data? All of it? What is the reliability? - When we adopt the schema, can we tinker with it to suit our needs? Again, could you please give some example of what to import and how should it be adapted? If the answers to these questions are yes, what is the point in procrastinating??? Do we have already all the datatypes that would be needed? Most of the properties that are missing is because of the lack of value or others. One other big thing of DBpedia is that it is connected to many external resources. This will make it possible to verify our data against these other sources. This is imho the more important thing to do with the time of our volunteers. Doing the things that have already been done is a waste of time. The thing is that if those resources already are in dbpedia, we can just use dbpedia as a bridge, that is how linked data is supposed to be... no need to replicate everything, but of course, if it is worth replicating, we can go through case by case. Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Dimitris Kontokostas Department of Computer Science, University of Leipzig Research Group: http://aksw.org Homepage:http://aksw.org/DimitrisKontokostas ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] claims Datatypes inconsistency suspicion
Am 25.08.2013 19:19, schrieb Markus Krötzsch: If we have an IRI DV, considering that URLs are special IRIs, it seems clear that IRI would be the best way of storing them. The best way of storing them really depends on the storage platform. It may be a string or something else. I think the real issue here is that we are exposing something that is really an internal detail (the data value type) instead of the high level information we actually should be exposing, namely property type. I think splitting the two was a mistake, and I think exposing the DV type while making the property type all but inaccessible makes things a lot worse. In my opinion, data should be self-descriptive, so the *semantic* type of the property should be included along with the value. People expect this, and assume that this is what the DV type is. But it's not, and should not be used or abused for this purpose. Ideally, it should not matter at all to any 3rd party if use use a string or IRI DV internally. The (semantic) property type would be URL, and that's all that matters. I'm quite unhappy about the current situation; we are beginning to see the backlash of the decision not to include the property type inline. If we don't do anything about this now, I fear the confusion is going to get worse. -- daniel ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] claims Datatypes inconsistency suspicion
Hi Daniel, if I understand you correctly, you are in favour of equating datavalue types and property types. This would solve indeed the problems at hand. The reason why both kinds of types are distinct in SMW and also in Wikidata is that property types are naturally more extensible than datavalue types. CommonsMedia is a good example of this: all you need is a custom UI and you can handle new data without changing the underlying data model. This makes it easy for contributors to add new types without far-reaching ramifications in the backend (think of numbers, which could be decimal, natural, positive, range-restricted, etc. but would still be treated as a number in the backend). Using fewer datavalue types also improves interoperability. E.g., you want to compare two numbers, even if one is a natural number and another one is a decimal. There is no simple rule for deciding how many datavalue types there should be. The general guideline is to decide on datavalue types based on use cases. I am arguing for diversifying IRIs and strings since there are many contexts and applications where this is a crucial difference. Conversely, I don't know of any application where it makes sense to keep the two similar (this would have to be something where we compare strings and IRIs on a data level, e.g., if you were looking for all websites with URLs that are alphabetically greater than the postcode of a city in England :-p). In general, however, it will be good to keep the set of basic datavalue types small, while allowing the set of property types to grow. The set of base datavalue types that we use is based on the experience in SMW as well as on existing formats like XSD (which also has many derived types but only a few base types). As for the possible confusion, I think some naming discipline would clarify this. In SMW, there is a stronger difference between both kinds of types, and a fixed schema for property type ids that makes it easy to recognise them. In any case, using string for IRIs does not seem to solve any problem. It does not simplify the type system in general and it does not help with the use cases that I mentioned. What I do not agree with are your arguments about all of this being internal. We would not have this discussion if it were. The data model of Wikidata is the primary conceptual model that specifies what Wikidata stores. You might still be right that some of the implementation is internal, but the arguments we both exchange are not really on the implementation level ;-). Best wishes Markus, offline soon for travelling On 26/08/13 10:35, Daniel Kinzler wrote: Am 25.08.2013 19:19, schrieb Markus Krötzsch: If we have an IRI DV, considering that URLs are special IRIs, it seems clear that IRI would be the best way of storing them. The best way of storing them really depends on the storage platform. It may be a string or something else. I think the real issue here is that we are exposing something that is really an internal detail (the data value type) instead of the high level information we actually should be exposing, namely property type. I think splitting the two was a mistake, and I think exposing the DV type while making the property type all but inaccessible makes things a lot worse. In my opinion, data should be self-descriptive, so the *semantic* type of the property should be included along with the value. People expect this, and assume that this is what the DV type is. But it's not, and should not be used or abused for this purpose. Ideally, it should not matter at all to any 3rd party if use use a string or IRI DV internally. The (semantic) property type would be URL, and that's all that matters. I'm quite unhappy about the current situation; we are beginning to see the backlash of the decision not to include the property type inline. If we don't do anything about this now, I fear the confusion is going to get worse. -- daniel ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] DNB 11M bibliographic records as CC0
Hi, Maybe this is interesting as an import source for bibliographic info http://blogs.ifla.org/bibliography/2013/08/06/german-national-library-offers-over-11-million-marc21-records-under-cc0-open-license/ Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] DNB 11M bibliographic records as CC0
This seems very interesting: maybe, there will be a time when Wikidata (or similar) will host the bibliographic records of thousands of libraries... Right now, I'm not sure if we want to discuss a massive upload of these records in WD, because: * they are in MARC, which is way more complex than the list of bibliographic properties currently in WD * they will be in German * do we really need so many records of books, articles and work, at this early stage? Aubrey On Mon, Aug 26, 2013 at 2:32 PM, David Cuenca dacu...@gmail.com wrote: Hi, Maybe this is interesting as an import source for bibliographic info http://blogs.ifla.org/bibliography/2013/08/06/german-national-library-offers-over-11-million-marc21-records-under-cc0-open-license/ Cheers, Micru ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] DNB 11M bibliographic records as CC0
There are many such CC0 national bibliographies available, and other large datasets, if the decision is made to import them. See here for a list: http://datahub.io/group/bibliographic Here is a direct link to the British National Bibliography page: http://bnb.bl.uk/ For further information on the open bibliographic project and the principles of open bibliographic metadata, check here: http://openbiblio.net http://openbiblio.net/principles Mark MacGillivray On Mon, Aug 26, 2013 at 1:51 PM, David Cuenca dacu...@gmail.com wrote: No, we don't need to import them all, but there was always the question if we were allowed to import that data from external sources. At least for the DNB that question has been settled. Cheers, Micru On Mon, Aug 26, 2013 at 8:37 AM, Andrea Zanni zanni.andre...@gmail.comwrote: This seems very interesting: maybe, there will be a time when Wikidata (or similar) will host the bibliographic records of thousands of libraries... Right now, I'm not sure if we want to discuss a massive upload of these records in WD, because: * they are in MARC, which is way more complex than the list of bibliographic properties currently in WD * they will be in German * do we really need so many records of books, articles and work, at this early stage? Aubrey On Mon, Aug 26, 2013 at 2:32 PM, David Cuenca dacu...@gmail.com wrote: Hi, Maybe this is interesting as an import source for bibliographic info http://blogs.ifla.org/bibliography/2013/08/06/german-national-library-offers-over-11-million-marc21-records-under-cc0-open-license/ Cheers, Micru ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l ___ Wikisource-l mailing list wikisourc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikisource-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] DNB 11M bibliographic records as CC0
If Wikidata has an ambition to be a really reliable database, we should do eveything we can to make it easy for users to use any source they want. In this perspective, if we got datas with guaranted high quality, it make it easy for Wikidatian to find and use these references for users. Entering a reference in the database seems to me a highly fastidious, boring, and easily automated task. With that in mind, any reference that the user will not have to enter by hand is something good, and import high quality sources datas should pass every Wikidata community barriers easily. If there is no problem for the software to handle that many information, I say we really have no reason not to do the imports. Tom ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Cooperation between Wikidata and DBpedia and Wikipedia
On 8/26/13 4:34 AM, Gerard Meijssen wrote: Hoi, Two things to consider; the Wikipedia community and the Wikidata community are two separate entities. As far as I am concerned, Wikidata needs more data to get to the tipping point where it becomes useful to users. I am really vocal about both. The license has traditionally been a sticking point and the not invented here aspect of DBpedia is as well. What is this not invented here aspect of DBpedia? You are effectively outside the Wikipedia community.. The other part is that the data of Wikidata is continually updated while DBpedia is not. What do you mean by that? Are you referring to schema/ontology/vocabulary evolution or instance data evolution? Remember, there are live editions of DBpedia. So in my opinion the best thing that can happen is when DBpedia DOES update with Wikidata. The point is not to absorb it without thinking. Yes, the first point of clarity would be when Wikidata produces a dump that can be ingested by DBpedia and any other data space in the LOD cloud. All that's required is data publication in Linked Data form. What DBpedia has is a set of properties that work on the data that it has gleaned from the many Wikipedias. There is undoubtedly a lot of documentation on it and, it would be good when this is taken into consideration when accepting and proposing new properties for Wikidata. Obviously only the properties that are currently supported can be proposed at this time. I am quite willing to propose properties based on DBpedia (but so can you). With the properties in place, we can import data. We can import it from both DBpedia and from Wikipedia. Sanity checks are needed for both sources and as far as I am aware we do not have sanity checks at Wikidata. What we do have is the possibility to compare data with other sources and that is where the Wikidata community needs to grow and that is why we need much data in the first place in order to get into this. However, we can start building the tools to do this. I hope the DBpedia community can help us with that. Thanks, GerardM As far as I know, DBpedia has always been interested in collaboration with Wikidata. Kingsley On 26 August 2013 09:16, Dimitris Kontokostas kontokos...@informatik.uni-leipzig.de mailto:kontokos...@informatik.uni-leipzig.de wrote: Speaking from DBpedia (not on behalf), we have been always trying to find ways to contribute data back to wikipedia and If licencing is the only issue here I am sure we can make any necessary arrangements. imho the main scepticism so far was trust from the WIkipedia community to load data in bulk. However, there are datasets of very high quality in DBpedia that could be used for that purpose. Recently we are experimenting in an alternative where people can manually import single facts in Wikidata from the DBpedia resource interface. Here's a recent talk about this [1] on the tech list. Any comments on that are also welcome. Best, Dimitris [1] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-August/000189.html On Fri, Aug 23, 2013 at 6:18 PM, David Cuenca dacu...@gmail.com mailto:dacu...@gmail.com wrote: Hi, I will answer with questions with more questions... On Fri, Aug 23, 2013 at 10:58 AM, Gerard Meijssen gerard.meijs...@gmail.com mailto:gerard.meijs...@gmail.com wrote: Hoi, The questions are: * would we advance a lot when we adopt the DBpedia schema as it is? Which schema? All of them? Some? Article classification? Infobox extraction? Wikidata is going to be linked to the infoboxes in Wikipedia, so the priority is to support those needs, not to replicate any schema. * Would we be open to include substantially more data? Which data? All of it? What is the reliability? * When we adopt the schema, can we tinker with it to suit our needs? Again, could you please give some example of what to import and how should it be adapted? If the answers to these questions are yes, what is the point in procrastinating??? Do we have already all the datatypes that would be needed? Most of the properties that are missing is because of the lack of value or others. One other big thing of DBpedia is that it is connected to many external resources. This will make it possible to verify our data against these other sources. This is imho the more important thing to do with the time of our volunteers. Doing the things that have already been done is a waste of time. The thing is that if those resources already are in dbpedia, we can just use dbpedia as a bridge, that is how
Re: [Wikidata-l] [Wikisource-l] DNB 11M bibliographic records as CC0
If the problem is to automate bibliographic data importing, a solution is what you propose, to import everything. Another one is to have an import tool to automatically import the data for the item that needs it. In WP they do that, there is a tool to import book/journal info by ISBN/doi. The same can be done in WD. Micru On Mon, Aug 26, 2013 at 9:23 AM, Thomas Douillard thomas.douill...@gmail.com wrote: If Wikidata has an ambition to be a really reliable database, we should do eveything we can to make it easy for users to use any source they want. In this perspective, if we got datas with guaranted high quality, it make it easy for Wikidatian to find and use these references for users. Entering a reference in the database seems to me a highly fastidious, boring, and easily automated task. With that in mind, any reference that the user will not have to enter by hand is something good, and import high quality sources datas should pass every Wikidata community barriers easily. If there is no problem for the software to handle that many information, I say we really have no reason not to do the imports. Tom ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikisource-l] DNB 11M bibliographic records as CC0
I know, I started a discussion about porting the bot to WIkidata in scientific Journal Wikiproject. One answer I got : the bot owner had other things to do in his life than running the bot and was not around very often any more. Having everiyhing in Wikidata already will be a lot more reliable and lazier, no tool that works one day but not the other one, no effort to tell the newbies that they should go to another website, no significant problem. Maybe one opposition would be that the data would be vandalised easily, but maybe we should find a way to deal with imported sourced datas which have no real reason to be modified, just marked deprecated or updated by another import from the same source. 2013/8/26 David Cuenca dacu...@gmail.com If the problem is to automate bibliographic data importing, a solution is what you propose, to import everything. Another one is to have an import tool to automatically import the data for the item that needs it. In WP they do that, there is a tool to import book/journal info by ISBN/doi. The same can be done in WD. Micru On Mon, Aug 26, 2013 at 9:23 AM, Thomas Douillard thomas.douill...@gmail.com wrote: If Wikidata has an ambition to be a really reliable database, we should do eveything we can to make it easy for users to use any source they want. In this perspective, if we got datas with guaranted high quality, it make it easy for Wikidatian to find and use these references for users. Entering a reference in the database seems to me a highly fastidious, boring, and easily automated task. With that in mind, any reference that the user will not have to enter by hand is something good, and import high quality sources datas should pass every Wikidata community barriers easily. If there is no problem for the software to handle that many information, I say we really have no reason not to do the imports. Tom ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Cooperation between Wikidata and DBpedia and Wikipedia
Hoi, As you may have noticed there are other people on the CC.. The not invented here refers to much of the Wiki world.. things get done but much is done over and over again EVEN when cooperation is easy and obvious. I have largely resigned myself to it, it is probably part of our persona. However, it is not in the best interest of our users. The people I originally wrote to are more DBpedia ... and very much Wikimedia as well. I do not remember that DBpedia has a live component, love to learn more.. I do know how much the DBpedia people want to reach out and connect in any positive way with both Wikipedia and Wikidata. It is something that would work wonders because it can speed up the addition of new properties, the import of wholesale data AND it may have us add the processes they have build to curate the data. grin and additional point would be that we include some academia at the same time /grin Thanks, GerardM On 26 August 2013 15:27, Kingsley Idehen kide...@openlinksw.com wrote: On 8/26/13 4:34 AM, Gerard Meijssen wrote: Hoi, Two things to consider; the Wikipedia community and the Wikidata community are two separate entities. As far as I am concerned, Wikidata needs more data to get to the tipping point where it becomes useful to users. I am really vocal about both. The license has traditionally been a sticking point and the not invented here aspect of DBpedia is as well. What is this not invented here aspect of DBpedia? You are effectively outside the Wikipedia community.. The other part is that the data of Wikidata is continually updated while DBpedia is not. What do you mean by that? Are you referring to schema/ontology/vocabulary evolution or instance data evolution? Remember, there are live editions of DBpedia. So in my opinion the best thing that can happen is when DBpedia DOES update with Wikidata. The point is not to absorb it without thinking. Yes, the first point of clarity would be when Wikidata produces a dump that can be ingested by DBpedia and any other data space in the LOD cloud. All that's required is data publication in Linked Data form. What DBpedia has is a set of properties that work on the data that it has gleaned from the many Wikipedias. There is undoubtedly a lot of documentation on it and, it would be good when this is taken into consideration when accepting and proposing new properties for Wikidata. Obviously only the properties that are currently supported can be proposed at this time. I am quite willing to propose properties based on DBpedia (but so can you). With the properties in place, we can import data. We can import it from both DBpedia and from Wikipedia. Sanity checks are needed for both sources and as far as I am aware we do not have sanity checks at Wikidata. What we do have is the possibility to compare data with other sources and that is where the Wikidata community needs to grow and that is why we need much data in the first place in order to get into this. However, we can start building the tools to do this. I hope the DBpedia community can help us with that. Thanks, GerardM As far as I know, DBpedia has always been interested in collaboration with Wikidata. Kingsley On 26 August 2013 09:16, Dimitris Kontokostas kontokos...@informatik.uni-leipzig.de wrote: Speaking from DBpedia (not on behalf), we have been always trying to find ways to contribute data back to wikipedia and If licencing is the only issue here I am sure we can make any necessary arrangements. imho the main scepticism so far was trust from the WIkipedia community to load data in bulk. However, there are datasets of very high quality in DBpedia that could be used for that purpose. Recently we are experimenting in an alternative where people can manually import single facts in Wikidata from the DBpedia resource interface. Here's a recent talk about this [1] on the tech list. Any comments on that are also welcome. Best, Dimitris [1] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-August/000189.html On Fri, Aug 23, 2013 at 6:18 PM, David Cuenca dacu...@gmail.com wrote: Hi, I will answer with questions with more questions... On Fri, Aug 23, 2013 at 10:58 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The questions are: - would we advance a lot when we adopt the DBpedia schema as it is? Which schema? All of them? Some? Article classification? Infobox extraction? Wikidata is going to be linked to the infoboxes in Wikipedia, so the priority is to support those needs, not to replicate any schema. - Would we be open to include substantially more data? Which data? All of it? What is the reliability? - When we adopt the schema, can we tinker with it to suit our needs? Again, could you please give some example of what to import and how should it be adapted? If the answers to these questions are yes, what is the point in
[Wikidata-l] WikiData DBpedia Dump Release v.0.1
Hello All, as an output of GSoC2013 project , Wikidata integration inside DBpediahttp://wiki.dbpedia.org/gsoc2013/ideas/WikidataMappings?v=hz9 we are happy to announce that an initial RDF DBpedia Dumps for Wikidata Data is now available. (details and examples for each dump will be in the download section in the wikipage) this is an initial Dump , so your Feedback is needed of course to review the exported data and enhance it. You can find more information and details here: https://github.com/hadyelsahar/extraction-framework/wiki/WikiData-DBpedia-Dump-Release-v.0.1https://github.com/hadyelsahar/extraction-framework/wiki/WikiData-DBpedia-Dump-Release-v.0.1 (There is also a list of known issues at the bottom of the wikipage) Thanks Regards - Hady El-Sahar Research Assistant Center of Informatics Sciences | Nile Universityhttp://nileuniversity.edu.eg/ ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Data acccess for Wikivoyage and bugfixes plus testing needed for the URL datatype
Heya folks :) Wikiyovage now has access to the data on Wikidata - meaning they got phase 2. With this the first sister project is fully supported \o/ The next sister projects will follow. More information on this soon. We've also just updated the software here. This brings a number of bug fixes and other improvements. The ones that are probably most important for you: * The copyright warning no longer pops up again when you change your language * There is now a new special page to list items/properties without a description in a given language. Thanks for the patch by Bene*. * The message that pops up when you want to add a link to an item which is already in use in another item has been improved. Thanks for the patch by Nemo bis. * Broken links to set sitelinks for Wikivoyage in the non-JavaScript version have been fixed. ([[bugzilla:51914]], [[bugzilla:52095]]) * The automatic comments for edits have been improved. They are more detailed now. * API: You can now provide custom edit summaries for edits via the API. * API: You can undo a revision via the API. * API: Bot edits via the setclaim API module are now marked as such ([[bugzilla:50933]]). * API: Precision and globe parameters are now required for geocoordinate data. * Starting in a few days a Wikidata edit that shows up in recent changes and watchlist on the client (Wikipedia/Wikivoyage) is going to be marked with a D. Thanks for the patch by umherirrender. Unfortunately we were not able to put the URL datatype on the test system on time for this deployment. It didn't get enough testing so we couldn't deploy it today with a good concious. We know you're waiting for this but it's better to give it a bit more testing and roll it out in 2 weeks with the next deployment. The URL datatype is now live for real on test.wikidata.org for you to try. Please give it a try and report any bugs you encounter. Please let me know if there are any issues. Oh and one more thing: Abraham, Denny and I sat down for an evening trying to captchure what Wikidata is about in a video. Hope you like it :) http://www.wikidata.org/wiki/File:Wikidata%27s_World.webm Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data acccess for Wikivoyage and bugfixes plus testing needed for the URL datatype
Hi, great news! Wiadomość napisana przez Lydia Pintscher lydia.pintsc...@wikimedia.de w dniu 27 sie 2013, o godz. 00:05: * Broken links to set sitelinks for Wikivoyage in the non-JavaScript version have been fixed. ([[bugzilla:51914]], [[bugzilla:52095]]) Small correction: this affected all sitelinks (of course in non-js editing). Michał ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data acccess for Wikivoyage and bugfixes plus testing needed for the URL datatype
On Tue, Aug 27, 2013 at 12:11 AM, Michał Łazowik mlazo...@me.com wrote: Hi, great news! Wiadomość napisana przez Lydia Pintscher lydia.pintsc...@wikimedia.de w dniu 27 sie 2013, o godz. 00:05: * Broken links to set sitelinks for Wikivoyage in the non-JavaScript version have been fixed. ([[bugzilla:51914]], [[bugzilla:52095]]) Small correction: this affected all sitelinks (of course in non-js editing). Ah thanks! I'll fix the project chat message. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
