Re: [Wikidata-l] External identifiers vs. Wikidata-internal links data
Hi all, On a side note I would like to mention that labels and aliases are external identifiers, perhaps not as accurate as database IDs, as natural language users tend to stretch the conceptual boundaries, but they can also be referenced and sourced. If, as Lydia says, database IDs will have their own section (either only in the frontend, or also in the backend), I would recommend to use a similar method for sourcing+qualifying labels, as natural language identifiers and database identifiers share the same problems. On Freebase, database keys had a separate tab. Not sure if that is the right approach... Cheers, Micru On Sat, Apr 4, 2015 at 3:45 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 4 April 2015 at 10:20, Thomas Douillard thomas.douill...@gmail.com wrote: I guess a class of properties ''external identifier definition property'' with isbn instance of external identifier prop could be useful as well. The property for an ORCID iD (P 496), for example, is an instance of Wikidata property for authority control for people (Q19595382). That, in turn is a sub-class of Wikidata property for authority control (Q18614948) -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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] Sitelinks to Redirects
On Wed, Oct 22, 2014 at 10:47 AM, svetlana svetl...@fastmail.com.au wrote: If we have a need in pointing (at Wikibase/Wikidata) to redirects on a regular basis, it might be time to rethink the relevant project design. I think that rethinking the project design is the right approach here. To link to redirects is as bad as leaving relevant article sections unconnected. The challenge is to find another way to associate an article section with an item without using redirects. I have opened a bug report to gather ideas: https://bugzilla.wikimedia.org/show_bug.cgi?id=72347 Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Associating WD items with WP article sections (it was: redirects, workflow)
Another thing that I am seeing now is that parsoid plans to add IDs to all elements: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec/Element_IDs I don't know enough about it to see if those element IDs could be used as section identifiers, but it might be well worth to ask about it. Cheers, Micru On Mon, Oct 20, 2014 at 10:24 PM, James Heald j.he...@ucl.ac.uk wrote: I think we have to look at what people actually use: overwhelmingly, that is redirects, not labelled section transclusion. Redirects are lightweight, in terms of editor time, and they do the job. Transclusion is of course valuable in particular cases; but trying to maintain multiple different contexts for the same material would be quite a headache - tricky to create and maintain, and utterly inflexible if somebody wants to re-shape the article. The bottom line here is that we should face reality: people are not going to create labelled section transclusions, still less have to put up with maintaining them, just to make wikidata have some more sitelinks. Realisticly, we would end up with a handful of such transclusions, at most. Whereas people create redirects every day. Yes, a redirect is just a redirect. It's not perfect. But it's usually good enough. Take Daniel Havell for instance: https://en.wikipedia.org/w/index.php?title=Daniel_Havell the section it points to is recognisably part of a larger article. In fact it has been written to be part of that larger article, and depends on it for context. The section is not standalone content. This is the deal with redirects, one which I do believe readers understand and accept. Yes, if somebody changed the section name, the redirect would no longer point to the section (unless they had left an anchor). But the redirect would still point to the right article; and given that at best redirects are just redirects, and depend on the rest of the article for context anyway, the less precise link is not *such* a big loss. The key thing about allowing sitelinks to redirects is that they are the mechanism that is actually used. The sitelink should point to where on the wiki there is content that matches the actual meaning of the item. If that happens to be a redirect, so be it. The best can be the enemy of the good. I simply do not believe that labelled section transclusions will happen to any great degree; and I think editors would find even those that did to be an endless pain to maintain. They are not a promise for which it is worth sacrificing the benefits of all the redirects we should and could be sitelinking to. -- James. On 20/10/2014 20:44, Derric Atzrott wrote: There are major problems using redirects as sitelinks. The top one is that they do not always point to the concept they should, and even if they do, there is no guarantee that this redirect will keep pointing to the same place (normally to a section of another article), since the section title can change. Wikipedia supports section labelling: https://en.wikipedia.org/wiki/Help:Labeled_section_transclusion I would support this as a solution. It seems to solve the issue that using redirects in site links wishes to solve. Thank you, Derric Atzrott ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] How to express property constraints correctly?
I'm thinking of possible ways to represent constraints as items (see [1]), like those in: https://www.wikidata.org/wiki/Property_talk:P19 However some of these are not easy to translate into Wikidata proper. For example: place of birth (P19) Conflicts with instance of (P31): criminal delict (Q1456832) With the current tools it could be expressed as convolutely as wished for, but it won't be compatible with the semantic web. Of course it would be much nicer and compatible to implement OWL2 property restrictions (some_values_from, all_values_from, none_of, etc) as snak types which could be re-used for any property. Then it would be as easy as: place of birth (P19) property restriction [none of] instance of (P31): criminal delict (Q1456832) Thoughts? Cheers, Micru [1] https://www.wikidata.org/wiki/Wikidata:Constraint_violation_report_input [2] http://www.w3.org/TR/owl2-syntax/#Object_Property_Restrictions ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
On Sat, Oct 18, 2014 at 1:12 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 18 October 2014 08:15, Gerard Meijssen gerard.meijs...@gmail.com wrote: I think I requested P1472, I forgot all about it. It takes so long before The proposal was mine: https://www.wikidata.org/wiki/Property_talk:P1472 Actually there where two proposals, the one by Gerard was submitted in January https://www.wikidata.org/wiki/Wikidata:Property_proposal/Sister_projects#Commons_Creator Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
On Sun, Oct 19, 2014 at 6:54 PM, rupert THURNER rupert.thur...@gmail.com wrote: would it make sense to use wikidata for such tasks as well? Wikidata already represents more granular information than an article, the real problem is that the only way that we have to bind a piece of information in Wikipedia to its Wikidata representation is through the article name. This is of course derived from the technological limitations of mediawiki which treats each article as a blob of text. On Wikisource we use Labeled Section Transclusion to define regions of a mediawiki page that can be transcluded into other pages: https://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion It is normally used with the following format: ## stable_section_identifier ## some text here In a way, it is like creating a local variable, since you assign an identifier to a section that later on can be referred to regardless of the changes in the text or in the title. I wonder if this is something that could be adapted for Wikipedia in a way that users could mark article sections with unique identifiers and then link those stable section identifiers in Wikidata. Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Item both subclass and instance?
Hi Eric, The idea is to separate in those edge cases the perceptual model (what is recognized) from the name given to it. As such you can consider ethanol and chemical compound metaclasses (names) pointing to a label-less class that represents the model. In practical terms what it would entail is: - remove the labels from Q153 - create one item for the label ethanol and one item for the label chemical compound - link Q153 with those names using has name - ethanol is no longer an instance, but a class that can take different names, ethanol being more specific Do you realize that after this scrap everything and start again from the beginning the resulting structure is more comprehensive and encompasses previous efforts? Entity stays as it is, but now it can be examined by its qualities and they can be taken apart if needed. The term cognizable is 1:1 compatible with the subclass/instance model, but it emphasizes the necessity of having an observer for it to be meaningful. Classes do not exist in isolation, it is in fact very naive to keep the notion of objectivity when dealing with observation. Even logic needs a system to be executed, and based on which reality models? How were they produced? And how are those models and the models based on them verified? The problem with logicians is that they think themselves isolated from the world, however even they were born from a womb. And have you seen who introduced the term negentropy? If you check the names behind it you will see that those ideas are in fact standing on the shoulders of giants. It is hard to model life without understanding first that life itself is survival-oriented. Those papers are interesting but fail to address basic questions like: who decides identity? How does the observer interact with it? Where does information come from? And without tackling those questions, and by extension, emergent processes, logic seems like a deux ex machina that appears from nothingness and acts in nothingness. Best, Micru On Sun, Oct 5, 2014 at 6:49 PM, Emw emw.w...@gmail.com wrote: Hi David, How does your treatise relate to the fact that https://www.wikidata.org/wiki/Q153 has statements that entail the following? [1] ethanol *instance of* chemical compound *subclass of* chemical compound How would it resolve that specific problem? Such statements make Wikidata incompatible with ChEBI and other major ontologies, like Gene Ontology and Disease Ontology, which use *instance of* (i.e. rdf:type, P31) and *subclass of* (i.e. rdfs:subClassOf, P279, is_a) as recommended in the Relation Ontology (RO) [2] and the Basic Formal Ontology (BFO). For Wikidata to be interoperable with other major ontologies in the Semantic Web, we cannot scrap everything and start again from the beginning. We must stand on the shoulders of giants. Doing away with entity [3] as a the top of the *subclass of* hierarchy and introducing a raft of idiosyncratic ontological constructs like identifiables, cognizables, negentropy and system survival-oriented direction to Wikidata is probably not the way to go. Regarding your concerns about the ability of existing approaches to represent emergent properties and natural language, I recommend perusing [4], an influential paper that informs DOLCE and BFO -- particularly the section on The Role of Identity Criteria. I also highly recommend lectures 3 and 1 in http://ontology.buffalo.edu/smith/IntroOntology_Course.html for gaining a perspective on how BFO maintainers think about things like distinguishing objects and representations, and that upper ontology's philosophical roots. Given your interest in phenomenology and Husserl, you may also be interested in what BFO maintainers have written on those subjects in e.g. [5] with regard to ontology. Best, Eric [1] https://www.wikidata.org/wiki/Q153 currently states ethanol *subclass of* alcohol, but given alcohol *subclass of* organic compound and organic compound *subclass of* chemical compound, it is entailed that ethanol *subclass of* chemical compound. [2] Barry Smith et al. (2005). *Relations in Biomedical Ontologies*. http://genomebiology.com/2005/6/5/r46 [3] Entity item on Wikidata. https://www.wikidata.org/wiki/Q35120. Mapped to owl:Thing. [4] Nicola Guarino (1998). *Some Ontological Principles for Designing Upper Level Lexical Resources*. http://arxiv.org/pdf/cmp-lg/9809002v1 [5] Barry Smith (1989). *Husserl: Logic and Formal Ontology*. http://ontology.buffalo.edu/smith/articles/lfo.html -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Item both subclass and instance?
Hi Eric, I have been following this issue for a long time, and I haven't found any satisfactory answer from anyone or from any source. Totally disappointed I decided to scrap everything and start again from the beginning, working on a foundation that eventually would allow to represent emergent systems and natural language. Pulling from that thread I got some interesting insights, that I hope you find useful: https://docs.google.com/document/d/1dc99zyxdPX8t6Ept_JjSxNalij2PNdYt-A3TG2e4cIw/edit?usp=sharing If you don't have time or patience to read the whole 27 pages (which is just an introduction that needs refinement and to be expanded): - in real life there is no difference between calling something metaclass, identifier or information, they all refer to an observer system encoding an observed signal together with a pattern recognition model - in real life instantiation is an observer system putting a frame on an observed system. This frame might be more or less justified considering the intrinsic qualities of what is placed inside, but in the end it is entirely observer-defined, so quite useless other than to point to an agreed or arbitrary bottom concept chosen by the observer ( I want to emphasize in real life because sometimes I notice a focus in devising mathematical sound approaches and not so much approaches based on reality itself. ) In my opinion the solution to atoms is to separate identifiers from the entity with a new property (has/identifier of or has/manifestation of) and use instance_of only when really necessary. I hope we don't have to resort to Captain Metaphysics :) http://existentialcomics.com/comic/47 Cheers, Micru On Fri, Sep 26, 2014 at 2:59 PM, Emw emw.w...@gmail.com wrote: The statement ethanol *instance of* chemical compound is ontologically incorrect. Importantly, it is also incompatible with ChEBI, the most widely-used chemistry ontology. The matter of how to apply *instance of* (P31, rdf:type) and *subclass of* (P279, rdfs:subClassOf) on Wikidata in relation to chemical entities has been, as Thomas puts it, a long discussion [1-5]. Hopefully with a wider audience and experts like Markus Krötzsch and Denny Vrandečić now interested, we can come to a resolution at least in the particular domain of chemical compounds. Since it concerns interoperability with another large Semantic Web project, I have copied Janna Hastings and Alan Ruttenberg on this discussion. Janna coordinates ChEBI. Alan coordinates BFO, the upper ontology used by ChEBI and many other major ontologies in the natural sciences, like Gene Ontology and Disease Ontology. Denny indicates how the statement Porsche 356 *instance of *car would be incorrect in Wikidata even though Porsche 356 *is a* car is acceptable in everyday speech. Similarly, ethanol *instance of* chemical compound is incorrect in Wikidata even though ethanol *is a* chemical compound is acceptable in less formal contexts. A key difference between talk about cars and talk about chemicals is that, with cars, we have familiar terms like car model that distinguish concrete instances (that *particular* car you see on the street) from abstract instances (i.e. metaclasses, classes that are also instances, the *kind* of car that you see on the street). We do not have a well-known term like chemical model or chemical compound type to distinguish classes (types) of chemicals and instances (tokens) of chemicals. When one speaks of the properties of ethanol or hydrogen, it is understood that the subject is *all concrete, particular, spatiotemporal tokens, i.e. instances *of ethanol and hydrogen -- not just a specific ethanol molecule floating in that container before you on a Saturday with friends, but all molecules that we label ethanol everywhere. Thus, in order to formally classify ethanol itself as opposed to some particular ethanol molecule, we must say for an item like http://www.wikidata.org/wiki/Q153: ethanol *subclass of* chemical compound and not ethanol *instance of* chemical compound. (On Wikidata, the statement is more precisely ethanol *subclass of *alcohol, but it is entailed from the statements alcohol *subclass of* organic compound and organic compound *subclass of* chemical compound that ethanol *subclass of* chemical compound.) A common defense of statements like ethanol *instance of* chemical compound is that Wikidata will never have items about any concrete molecules of ethanol, so, since ethanol is a leaf node in our concept taxonomy, it makes sense to state that ethanol is an instance. That interpretation of instance is short-sighted. It precludes us from ever talking about particular tokens of ethanol, or particular aggregates of such objects, without overhauling our chemistry ontology. Excluding consideration of metaclasses like chemical compound type, the fact that an entity is a leaf node in a concept hierarchy is a necessary but not sufficient condition for
Re: [Wikidata-l] Linking to Wikipedia page using Wikidata ID
Hi Nick, I have opened this bug report where you can subscribe or add your use case (if you think my suggestion is not appropriate): https://bugzilla.wikimedia.org/show_bug.cgi?id=70159 There is also this related enhancement proposal for error handling: https://bugzilla.wikimedia.org/show_bug.cgi?id=70127 Regards, Micru On Thu, Aug 28, 2014 at 2:08 PM, Nicholas Humfrey nicholas.humf...@bbc.co.uk wrote: Fantastic, thanks! Could you put linking to the user's preferred language (Accept-Language header?) on the backlog? nick. From: David Cuenca dacu...@gmail.com Reply-To: Discussion list for the Wikidata project. wikidata-l@lists.wikimedia.org Date: Thursday, 28 August 2014 12:59 To: Discussion list for the Wikidata project. wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Linking to Wikipedia page using Wikidata ID Hi Nick, You are lucky, that feature has been released this week: https://www.wikidata.org/wiki/Special:GoToLinkedPage For instance https://www.wikidata.org/wiki/Special:GoToLinkedPage/enwiki/Q732383 Cheers, Micru On Thu, Aug 28, 2014 at 12:52 PM, Nicholas Humfrey nicholas.humf...@bbc.co.uk wrote: Hello, We have been working on associating every episode of BBC Desert Island Discs to a Wikipedia page about that person. Example: http://www.bbc.co.uk/programmes/p0093x3l http://en.wikipedia.org/wiki/David_Croft https://en.wikipedia.org/wiki/David_Croft http://www.wikidata.org/wiki/Q2072654 https://www.wikidata.org/wiki/Q2072654 Since we created some of the links to Wikipedia, those pages have changed into disambiguation pages. Is it possible to link to a Wikipedia page using the Wikidata ID, via some kind of redirect URL? Thus ensuring that we continue to link to the correct article? Ideally it would even link to the users preferred language… Thanks! nick. ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] new features deployed \o/
Lydia, I have a question about pages in Wikidata connected to their items. In the example you give: https://www.wikidata.org/wiki/Q914807 How can be the page linked? I guess I have to enter it in the section Pages on other sites linked to this item, but when I click add, there is no suggester. I tried wikidata, wikidatawiki, data, but nothing happens. By the way the Wikinews section appears as wikibase-sitelinks-wikinews, but probably you are already aware of it. Thanks for the update! Micru On Wed, Aug 20, 2014 at 8:10 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey folks :) As announced last week we just deployed a number of new features. Those are: * Wikinews is now able to manage its sitelinks via Wikidata. https://www.wikidata.org/wiki/Wikidata:Wikinews for questions/coordination/... * Wikidata is now also its own client. This means you can for example add a sitelink to Wikidata:Help to the item for all main help pages. You are able to make use of the data in items on other pages in Wikidata with Lua. (Arbitrary access has been enabled for Wikidata for this but when data in an item changes we will not be able to purge the page using the data yet.) * Sitelinks for projects with just one sitelink in the group (like Commons, Wikidata and in the future Meta for example) are now grouped together in one sitelink group. * Badges for good and featured articles can be stored on Wikidata right next to the sitelink. We have badges for featured and good articles. More can be added on request later. Thanks to Bene* and lazowik for this feature. * Redirects between items can be created. When two items are merged one of them can be turned into a redirect. This way our identifiers can be considered much more stable by 3rd parties for example. It also makes it unnecessary to delete duplicate items. This will reduce the workload of our admins considerably. * We have the new datatype monolingual text. This allows you to make statements with a string and an associated language. Known issues/limitations: * Redirects can so far only be created via the API * Arbitrary access on Wikidata to the data on Wikidata itself is only possible via Lua. The parser function still needs to be adapted. * Badges can not yet be shown on the Wikipedias etc. This will follow next week. * Diffs for badges changes have a link to a wrong target (https://bugzilla.wikimedia.org/show_bug.cgi?id=69758) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Announce: WikiProject Structured Data for Commons
Thanks for the stats, Gerard. Two thoughts: - With so many items without description I wonder why we don't have the automatic descriptions gadget enabled by default. - There are many items without statements, but not that many articles without a category -- would it be possible to have a game that suggests instance of/subclass of based on the statements of the items in the same or in the upper category? Thanks Micru On Tue, Aug 19, 2014 at 10:39 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I am not in research. I am into making Wikidata into a reasonable resource. To achieve this I add gazillions of statements and I am happy when people focus on templates. However without the data, templates that make use of Wikidata are niche applications. Without some mature understanding of what Wikidata is at this time concentrating on templates is an exercise in building enabling technology. My point is for the community to have reasonable expectations. So many people consider Wikidata to be useless. That is fine but imho it helps when the baseline of where Wikidata is at this time is understood. Thanks, GerardM The statistics that explain this best can be found here .. https://tools.wmflabs.org/wikidata-todo/stats.php?reverse On 19 August 2014 10:27, Luca Martinelli martinellil...@gmail.com wrote: Ok, I got the point. What you probably need to consider is that focusing on one goal does not mean at all that we have to dismiss all the others. At least, *I* do not think so. You want to focus on research? Fine, do it. I'd like to focus on templates. That's fine too, I guess. We're both working to let Wikidata be appreciated - by separate audiences. L. Il 19/ago/2014 07:57 Gerard Meijssen gerard.meijs...@gmail.com ha scritto: Hoi, What is the point of Wiktionary, WIkipedia, Wikispecies et al as a WMF project? Like Wikidata they all help us share in the sum of all knowledge. Wikidata already provides an application in being the vehicle for interlanguage links. The low hanging fruit of Wikidata is not sharing info in templates, it is in providing search results where a Wikipedia does NOT have an article. It is used for this and it does have a measurable impact. It is nice to have the ambition to share data in templates but be realistic. The quality of the data in Wikidata does not merit this at this time. The community insists on sources and frankly it is assassine to expect that in the first few years it will be available near the level that some demand. This is only based on the data that is there. That is the next problem we do not have enough data. We are still at the stage where we are harvesting data for the first time. Harvesting big amounts, not one item at a time. It is important to have goals, and it is nice that at the start providing data to templates was seen as an initial goal. However it will not be like with Pallas Athena when she came from the head of Zeus in full armour. This goal is achievable and we are making big strides in that direction BUT we need smaller goals, small applications that grow our content in both quality and quantity. As I wrote on my blog, we need to think in terms of confidence in our data and not so much in sources. Amir is finishing a tool that will allow us to compare data for humans in the English, German and Italian Wikipedia. That will be a massive step in the right direction. I care about Wikidata and I know that at this time those freakingly hard templates are the least of our worries. More problematic is that people think of Wikidata as a service product for Wikipedia and limit their thinking to templates. The existing search extension with WDQ is there. It works really well. It is dismissed probably because it demonstrates that ALL Wikipedias cover less than 50% of the subjects known to us. We know all of them because of Wikidata. So yeah by all means blow the horn about our aspiration of servicing templates in those projects that can handle this. It is fine. It is not realistic and even counter productive as an aspiration when we do not appreciate the reality as we have it at this time. Thanks, GerardM On 18 August 2014 14:41, Luca Martinelli martinellil...@gmail.com wrote: 2014-08-17 17:00 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com: Hoi, Importing data from Wikidata (where do you want it??) is just one application. There are so many potential applications for structured data and Wikidata implicitly covers the sum of all knowledge as we know it (in the Wikimedia projects) so there are opportunities galore. For people not to know how to is a given. I do not care to know about Wikipedia templates because they are freaking impossibly hard. Yet, if we don't use the Wikidata data in the freaking impossibly hard Wikipedia templates, what is the point of Wikidata as a Wikimedia project? I remember that this project had among its first
Re: [Wikidata-l] Commons Wikibase
Markus, is this related with the idea of creating a database of automatically inferred statements that you presented some time ago? Cheers, Micru On Tue, Aug 19, 2014 at 12:30 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 19.08.2014 12:20, Gerard Meijssen wrote: Hoi, I cannot parse this .. What Thomas is saying is that classification (putting things into categories) and querying (finding things based on certain properties) can be combined in a natural way. In ontology languages like OWL, you can make statements that say, roughly speaking, that all results of query A belong to class B. This allows you to build a classification partly automatically, and to ensure that your classification is always consistent with your data. From this perspective, you can view Wikidata's stored queries as similar to OWL's class expressions in that they allow you to define classes based on the data given for each item, without having to go through all the items to add classes manually. What Thomas is referring to is of course slightly more advanced still, but maybe this clarifies part of the idea. Cheers, Markus On 19 August 2014 11:43, Thomas Douillard thomas.douill...@gmail.com mailto:thomas.douill...@gmail.com wrote: Note that in Wikidata we are developping methods and tools to class items in « classes », which in short are sets of real world things or events. In languages like the w3c language and standards OWL2 https://en.wikipedia.org/wiki/OWL2. In this language you can assign a class to an element (a media in the common case) to a class (that can be seen as a better defined category) either by creating a statement « this media belongs to that category » (in Wikidata this is done by using the « instance of » property https://www.wikidata.org/wiki/Property:P31) or by associating a so called «class expression» in OWL (an analog of a query but more powerful) Then in OWL any item who satisfy the criteria of the query or class expression associated to a class belongs to that class without stating it explicitely. In short, the possibility to assign an arbitrary class to an item when a query is not enough will also be possible with just a metadata repository, we may in the future even be able to mix these two ways to class medias. 2014-08-19 10:14 GMT+02:00 James Heald j.he...@ucl.ac.uk mailto:j.he...@ucl.ac.uk: Also there might be queries one might want to run on the categories, which would be another reason to include them in Commons Wikibase. -- J. On 19/08/2014 07:00, Gerard Meijssen wrote: Hoi, I know the categories in Commons exist. I also know that you do not have to add categories when an image is uploaded. Many people do not consider the categories because they are just there and are not easy nor obvious without a long study. They are there and they evolve. When the community finds that they are no longer useful, there will be others who still want to work on it. They can, it is a harmless occupation. Why would we consider removing category structures as long as someone cares about them ?? Thanks, GerardM _ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org mailto:Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/__mailman/listinfo/wikidata-l https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org mailto: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 ___ 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] Announce: WikiProject Structured Data for Commons
It is possible to represent linguistic patterns as items but it needs some work to conceptualize a structure that can be used in several languages. Then you could implement a complex query that selects the one that displays the most information. The biggest hurdle I see is that we are not storing enough linguistic data. We could already do it without any further development, but I think that we need more time to understand thoroughly the structure that is emerging. Maybe it could be thought as a research project to explore the possibilities. On Tue, Aug 19, 2014 at 4:34 PM, Thomas Douillard thomas.douill...@gmail.com wrote: One answer would be deeper answer of autodescription into Wikidata. I don't know how to make this flexible and generic enough to make this only depedant of Wikibase model concept though. One rough and not thought throw proposition would be: associate a (mediawiki?) template to a query or a class for each language, which generates a description if an item matches the query according to the values of the properties. hen we could add an API call that uses the template. 2014-08-19 16:13 GMT+02:00 Lydia Pintscher lydia.pintsc...@wikimedia.de: On Tue, Aug 19, 2014 at 11:19 AM, David Cuenca dacu...@gmail.com wrote: Thanks for the stats, Gerard. Two thoughts: - With so many items without description I wonder why we don't have the automatic descriptions gadget enabled by default. I am a bit worried about enabling this by default for everyone as a gadget. We need the descriptions in a lot of places where people search for items. The next big one will be Commons. But _a lot_ more will come in the future. Think for example of tagging your blog post on Wordpress with Wikidata concepts. You'll need the descriptions. If we enable automatic descriptions on Wikidata now we will actively discourage people from entering more descriptions. That would be bad as 3rd parties then don't get the benefit of them. I am also hesitant to build this into Wikibase directly as it'd need quite some domain-knowledge for all I can tell at this point. That's something we need to avoid. Anyone got ideas how to get out of this? Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 ___ 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] Commons Wikibase
On Tue, Aug 19, 2014 at 5:59 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: I guess it is related, yes. Although currently I am first focussing on efficient query answering -- inference will come after that :-) Whether one stores the results in a database or not is an implementation detail, btw., that is maybe not essential for a user. Ok, ok, no hurries :-) Oh, and of course all of this seems to be rather off-topic for the current subject Commons Wikibase :-) All that is relevant there has already been said I guess (many categories could be expressed by queries to improve results; a gentle, community-led transition will be possible and preferred; categories won't be switched off just because Wikidata is switched on). Actually I have one last question :) At the moment Gerard is using is a list of:value on category item pages which has the effect of being the inverse of instance of. And then he adds further conditions as qualifiers, see: https://www.wikidata.org/wiki/Q6562 While this method of works for simple categories, more complex ones would be hard to model using this method, like https://www.wikidata.org/wiki/Q8380098 I was thinking of modelling it like: Category:Discoverers of extrasolar planets is a list of human Category:Discoverers of extrasolar planets has items used as value of discoverer Of course it would require to have a link between the item discoverer and the property discoverer, but would that make sense? Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Language code and site code in the links section
Would it be possible to lift the limitation of 1-sitelink = 1-wikipage for wikis that host several languages? In a way that: 1-sitelink + 1-language = 1-wikipage Or are there other technical limitations? Thanks Micru On Mon, Aug 18, 2014 at 3:38 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Sat, Aug 16, 2014 at 5:50 PM, David Cuenca dacu...@gmail.com wrote: There are 3 columns in the sitelink section: Language, Code and Linked page. Usually language-code and wiki-code have a permanent 1:1 correspondence , but not in all projects (incubator, meta, wikidata). Would it be possible to add a configuration option so that for wikis that host several languages the language code is also requested? In this case it would be better to change the column order to wiki code, language and linked page, that way the users would enter first the wiki-code and then if that wiki has the multiple language configuration enabled, it would request the language code as well. For wikis that have pages translated into multiple languages (meta, wikidata) the code mul can be used. Can you name a specific case where you'd want this? Even for wikis with several languages in one we can only link one page and have no way to distinguish between them. Or am I missing something? Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Summary #122
They are slightly different. One refers to the work the character appears in, and the other refers to the fictional universe. For instance: Frodo Baggins (Q177329) present in work The Lord of the Rings (Q15228) Frodo Baggins (Q177329) from narrative or fictional universe Tolkien's legendarium (Q81738) Cheers, Micru On Sun, Aug 17, 2014 at 3:34 PM, Sjoerd de Bruin sjoerddebr...@me.com wrote: Hello, So we have https://www.wikidata.org/wiki/Property:P1441 now. What's the difference between that property and https://www.wikidata.org/wiki/Property:P1080 ? Greetings, Sjoerd de Bruin sjoerddebr...@me.com Op 17 aug. 2014, om 15:27 heeft John Lewis johnflewi...@gmail.com het volgende geschreven: Hi everyone, You can view the latest summary at https://www.wikidata.org/wiki/Wikidata:Status_updates/2014_08_16. Discussions - Open RfOS: John F. Lewis https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Oversight/John_F._Lewis Other Noteworthy Stuff - Help choose which banner will be featured on the new Main page! Click here to view the two banner candidates https://www.wikidata.org/wiki/Wikidata:Portal_Redesign/Banner#Candidates and leave your feedback before August 20th 16:00 UTC. - Wikidata Translate https://tools.wmflabs.org/hay/wdtranslate, a Wikidata-based Google translator open source clone. Did you know? - Newest properties: journey destination https://www.wikidata.org/wiki/Property:P1444, score method https://www.wikidata.org/wiki/Property:P1443, grave picture https://www.wikidata.org/wiki/Property:P1442, present in work https://www.wikidata.org/wiki/Property:P1441, Fide ID https://www.wikidata.org/wiki/Property:P1440, Norsk filmografi ID https://www.wikidata.org/wiki/Property:P1439, Jewish Encyclopedia ID https://www.wikidata.org/wiki/Property:P1438, plea https://www.wikidata.org/wiki/Property:P1437, collection size https://www.wikidata.org/wiki/Property:P1436 - Newest WikiProjects https://www.wikidata.org/wiki/Wikidata:WikiProjects: WikiProject Movies https://www.wikidata.org/wiki/Wikidata:WikiProject_Movies Development - Finished a large number of new features and got them ready for roll-out. More in this email https://lists.wikimedia.org/pipermail/wikidata-l/2014-August/004328.html . - Wikibase made a big step forward to finally switch to DataModel 1.0. - Improved support for entity IDs bigger than 2 billion (32 bit integer). - We had to adapt Wikibase to some major changes (more major than usual, partly caused by discussions at Wikimania) in MediaWiki core: The default Vector skin became it’s own component and the ResourceLoader got some small but important updates. - Continued work on refactoring code of the user interface to make it ready for new design - Wrote a script to get number of users having wikidata in their recent changes/watchlist from the database See current sprint items http://sb.wmflabs.org/p/wikidata/ for what we’re working on next. You can see all open bugs related to Wikidata here https://bugzilla.wikimedia.org/buglist.cgi?emailcc1=1list_id=151540resolution=---emailtype1=exactemailassigned_to1=1query_format=advancedemail1=wikidata-bugs%40lists.wikimedia.org Monthly Tasks - Hack on one of these https://bugzilla.wikimedia.org/buglist.cgi?keywords=need-volunteer%2C%20keywords_type=allwordsemailcc1=1resolution=---emailtype1=exactemailassigned_to1=1query_format=advancedemail1=wikidata-bugs%40lists.wikimedia.orglist_id=162515 . - Help fix these items https://www.wikidata.org/wiki/Wikidata:The_Game/Flagged_items which have been flagged using Wikidata - The Game. - Help develop the next summary here! https://www.wikidata.org/wiki/Wikidata:Status_updates/Next - Contribute to a Showcase item https://www.wikidata.org/wiki/Wikidata:Showcase ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Language code and site code in the links section
There are 3 columns in the sitelink section: Language, Code and Linked page. Usually language-code and wiki-code have a permanent 1:1 correspondence , but not in all projects (incubator, meta, wikidata). Would it be possible to add a configuration option so that for wikis that host several languages the language code is also requested? In this case it would be better to change the column order to wiki code, language and linked page, that way the users would enter first the wiki-code and then if that wiki has the multiple language configuration enabled, it would request the language code as well. For wikis that have pages translated into multiple languages (meta, wikidata) the code mul can be used. Thanks Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] DBpedia - Wikidata mapping questions
Hi Marco, Thanks for getting in touch. Looking at the list there seems to be many wrong mappings. Is there any way that we can collaborate to increase the number of matches or does it have to do with qualifiers? And do you plan to document 1:1 matches on your OntologyProperty namespace? Thanks and regards, Micru On Wed, Aug 13, 2014 at 12:55 PM, Marco Fossati hell.j@gmail.com wrote: Hi everyone, The following spreadsheet contains the latest DBpedia - Wikidata mapping effort both for properties and classes (cf. the 2 sheets) made by the GSoC student so far. https://docs.google.com/spreadsheets/d/18W9xb5KXorotJ7qM58AsqK- myAHEjiDgnZrqNXHEnwk/edit#gid=716082733 Since I am his main mentor, feel free to ask me further details. Hope this helps! Cheers, Marco On 8/13/14, 9:14 AM, David Cuenca wrote: On Wed, Aug 13, 2014 at 12:55 AM, Daniel Kinzler daniel.kinz...@wikimedia.de mailto:daniel.kinz...@wikimedia.de wrote: I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata - dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata - dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know. Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. We should definitely map dpedia classes to wikidata items. Sergey Skovorodkin is working on a dbpedia-wikidata mapping as a GsoC for DBpedia this year https://github.com/dbpedia/extraction-framework/wiki/ GSoC-2014-Progress-Sergey-Skovorodkin I'm CCing him to see if he can report the status or if he might need help with our properties, maybe we are missing some or need to clarify some others. Sometimes we are using qualifiers to extend properties instead of creating new ones. Cheers, Micru -- Marco Fossati http://about.me/marco.fossati Twitter: @hjfocs Skype: hell_j -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] integration of VisualEditor and Wikidata
On Wed, Aug 13, 2014 at 12:55 AM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: I think it would be cool to use http://mappings.dbpedia.org/ - it already has mappings for hundreds of templates in different language versions to the dbpedia vocabulary. If we added a mapping for wikidata - dbpedia, it should be easy enough to derive a mapping between a wikipedia template and wikidata. Actually, I was under the impression the wikidata - dbpedia already existed, but I don't see it on the site right now. Adding Anja Jentzsch, she might know. Even if it proves too tricky to map individual template parameters this way, it should still be possible to at least detect the class (instanceof) of an item based on the templates the respective wikipedia page contains. We should definitely map dpedia classes to wikidata items. Sergey Skovorodkin is working on a dbpedia-wikidata mapping as a GsoC for DBpedia this year https://github.com/dbpedia/extraction-framework/wiki/GSoC-2014-Progress-Sergey-Skovorodkin I'm CCing him to see if he can report the status or if he might need help with our properties, maybe we are missing some or need to clarify some others. Sometimes we are using qualifiers to extend properties instead of creating new ones. Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata: CSV, Shapefile, etc.
Yuri and others, I asked not long ago in Commons and there is no opposition as long as it is for supporting visualizations. It would require modifying what is allowed in commons, though. There are interesting comments on the talk page https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets Data.wikisource.org could be another option, but it would require more effort to set up, and some time for discussions. Cheers, Micru On Wed, Aug 13, 2014 at 6:15 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: This can already be done by changing JsonConfig configuration. I propose we add a Data namespace to the *commons https://commons.wikimedia.org/*. Moreover, with the recent work on Graph https://www.mediawiki.org/wiki/Extension:Graph extension, I was thinking of storing graphing related data there as well. JsonConfig currently supports php-code-based validation, but adding json-schema https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=json%20schemasafe=off validation should not be too difficult. Data:* -- accepts any valid JSON, without additional validation Data:SubNamespace:* -- Custom validated domain-specific data For graphs, we might have shape data as well as statistics data. So we could declare: Data:Graph:* -- accepts JSON that represents entire graph -- vega http://trifacta.github.io/vega/ grammar, and Data:SomethingElse:* for all snippets of graphs that will be pulled in by the vega dynamically. Also, I could fairly easily add support for CSV and TSV if we decide that it is needed, so that Data:Tsv:* pages would be forced to have the same number of columns on each line. On Wed, Aug 13, 2014 at 11:48 AM, Dario Taraborelli dtarabore...@wikimedia.org wrote: There's a proposal I posted a while ago to store generic datasets that can be represented in a tabular or JSON format in a dedicated project namespace with dedicated handlers: http://meta.wikimedia.org/wiki/DataNamespace http://meta.m.wikimedia.org/wiki/DataNamespace There's some good discussion on the talk page on the differences between this type of data and structure data hosted on Wikidata and where this thing could live (it could live on any Wikimedia wiki, including Commons or Meta). It looks like this could be a good fit for shapefiles and I'd love to hear your thoughts if you have a moment to read this. Dario On Aug 5, 2014, at 8:43, Paul Houle ontolo...@gmail.com wrote: I'm intensely interested in links to shapefiles from databases such as Wikidata, DBpedia and Freebase. In particular I'd like to get Natural Earth hooked up http://www.naturalearthdata.com/ It's definitely a weakness of current generic databases that they use the 'point GIS' model that is so popular in the social media world. On Tue, Aug 5, 2014 at 10:14 AM, Magnus Manske magnusman...@googlemail.com wrote: We don't have shapefiles yet, but a lot of property types such as geographic coordinates (as in, one per item, ideally...), external identifiers (e.g. VIAF), dates, etc. A (reasonably) simple way to mass-add statements to Wikidata is this tool: http://tools.wmflabs.org/wikidata-todo/quick_statements.php A combination of spreadsheet apps, shell commands, and/or a good text editor should allow you to convert many CSVs into the tool's input format. Cheers, Magnus On Tue, Aug 5, 2014 at 3:01 PM, Brylie Christopher Oxley bry...@gnumedia.org wrote: I would like to contribute data to Wikidata that is in the form of CSV files, geospatial shapefiles, etc. Is there currently, or planned, functionality to store general structured data on Wikidata? -- Brylie Christopher Oxley http://gnumedia.org ___ 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 -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254paul.houle on Skype ontolo...@gmail.com ___ 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 ___ 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] integration of VisualEditor and Wikidata
On Wed, Aug 13, 2014 at 9:52 PM, James Forrester jforres...@wikimedia.org
wrote:
If the infobox really has no options and just builds itself entirely
automatically, why not just move it out of the wikitext/etc. content
entirely and display it always? This makes pages much easier to edit in
wikitext (no KiB of {{…}} at the top, no confusing stuff at all, nothing to
break) and simplifies a lot of things…
I support moving the infobox out of wikitext and into page settings, and
allowing only one infobox per article. Sometimes there are more than one
which makes things unnecesarly confusing. For instance:
https://en.wikipedia.org/wiki/Bonnie_and_Clyde
it could use an infobox group of humans that displays data of each person
in the group instead of using twice infobox person.
However I'm saying this as a Wikidatan and a rational person, not as
Wikipedian :)
Cheers,
Micru
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] {{Universal infocard}} in ruwiki, and cross-wiki coordination
Actually you don't even need to specify which infobox because that can be
automated using P1423 (infobox's main topic) and P1424 (topic's main
infobox). For instance if an item has instance of:person, then you can
check which infobox is connected to the item Q5 and use that infobox. These
properties are still not used widely, but there is no reason not to.
Since Wikidata will be soon its own client, then it is also possible to
store (and use) Lua modules on Wikidata and synchronize them across all
Wikipedias with a bot. However this is sometimes a bit tricky, since
Wikipedias usually like to have their own version. For instance in cawiki
the Authority template gives more relevance to Catalan registers and
contains translated text.
GerardM also suggested an article creation wizard that would first check
if the topic exists in Wikidata. If it does, the infobox could be
automatically inserted on creation. If it doesn't some basic facts could be
asked about the article to create a wikidata item. And based on that data
some automatic text could be generated. Magic! :)
Micru
On Tue, Aug 12, 2014 at 3:00 PM, Amir E. Aharoni
amir.ahar...@mail.huji.ac.il wrote:
Thanks to David's comment earlier today about editing , I found this page
in the Russian Wikipedia:
https://ru.wikipedia.org/wiki/Module:Universal_infocard
It's a Lua module that shows a person infobox, pulling the data from
Wikidata and without giving any parameters in the wiki source code.
This is essentially the fulfillment of Wikidata's promise to make editing
articles with infoboxes easier, and it's wonderful. There are more things
to do, but I already want to thank everyone involved.
But now the question of cross-wiki synchronization arises. Wikidata.org is
cross-wiki by definition. Templates such as {{Universal infocard}} should
be cross-wiki as well.
Why? To make translation easier. The article about the Slovak poet
Bohuslav Tablic is available in Russian, but not in English. I'd love to
translate it to English, but I'll have to use {{Infobox writer}} and fill
it manually with data. This is doable, but it would be far more efficient
to pull the data from Wikidata. This will become even more acute when the
ContentTranslation, and that should happen Some Time Soon. Millions of such
articles could be translated, and using Wikidata well will save the
translators millions of minutes.
I am not saying that all projects should have the same templates. For
example, I am not concerned with the visual design of the templates - this
is up to the communities and the designers. But the way in which the data
is used should be sync'ed.
What does it entail?
Synchronizing the code of the Lua modules? Can these, maybe, be made into
a Lua library that is maintained in MediaWiki source, rather than as
on-wiki modules?
Major cross-wiki collaboration in functional specification of data to be
used in infoboxes?
What else?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
___
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] integration of VisualEditor and Wikidata
@Bene*: The WE-Framework already has an interface for dealing with statement ranks, have you tried the latest version? https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:WE-Framework As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData Cheers, Micru On Tue, Aug 12, 2014 at 11:19 PM, Bene* benestar.wikime...@gmail.com wrote: Hello, My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item. The problem I see here is that we mostly do not want to replace a value but rather add another preferred one and state that the old one is now deprecated. This means, we also want to have the old major on the Wikidata item but the new major should be marked as preferred. I think we have to think a lot how this can be implemented best in Visual Editor. Maybe we should just add the value entered there just as another preferred value but this is rather a guess because the data might also be simply wrong and should be replaced. We thus have to investigate how often the value should be replaced and how often the old value should be kept as well. Then we can decide a way how the visual editor should use this data without being to complicated but also offering all options to create the data as intended. My acceptable-but-suboptimal scenario is taking the user to https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template (|mayor =[[Milan Ftáčnik]]) than to go to https://www.wikidata.org/wiki/Q6850543 and find the value. We might take the user to the item's page on Wikidata if he wants to make more enhanced edits like replacing an old edit. Does anybody have any more ideas about it? For the technical implementation, we have to find a way which data comes from which item and which property. Maybe we can add some data-item and data-property attributes to the HTML tag in which the data is stored so that the visual editor can easy find these transclusions. However, this might also be a security issue if the attributes are added to elements not containing Wikidata data. All in all, you are surely not late and this discussion has just started at Wikimania (although it is planned much longer to have something like that). Therefore, I think this feature hasn't hightes priority at the moment and needs lots of cooperation with the Visual Editor team. Perhaps we will start developing not before 2016. (Only my personal guess. :-) Best regards, Bene ___ 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] Great editor for Wikipedia infoboxes/templates connected to Wikidata
User:Vlsergey from ruwiki presented yesterday at the Wikidata Meetup a new wonderful infobox editor for Wikipedia infoboxes: https://www.wikidata.org/wiki/Wikidata:Project_chat#Edit_directly_from_infocard_.2F_infobox And also an improved authority template which you can see in action at Obama https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%B0%D0%BC%D0%B0,_%D0%91%D0%B0%D1%80%D0%B0%D0%BA#.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8 Plus some interfaces for editing person info, taxons, and work/edition source info: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/07#WEF_gadgets_update I think these are great improvements for editing wikidata from wikipedia and I hope you can spread the word in your local wikis about these wonderful tools. Thanks! Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] New initiative to promote friendliness
:D https://www.wikidata.org/wiki/Wikidata:Lounge/Jokes! I tried my best! :D *backs up slowly* On Tue, Jul 29, 2014 at 11:13 AM, Maximilian Klein isa...@gmail.com wrote: Thanks Mircu, this is a great idea with the right intentions. Max Klein ‽ http://notconfusing.com/ On Fri, Jul 25, 2014 at 9:46 PM, David Cuenca dacu...@gmail.com wrote: Exactly! That's the spirit, it is much better to cement openess and tolerance while they are there :) And just by setting up that page we'll have a place to chill out :) Thanks Micru On Fri, Jul 25, 2014 at 5:12 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 25/07/14 15:28, David Cuenca wrote: Worried about the harshness that lately has been developing, I have started a new initiative to counter that by promoting more dialogue, civility, and friendliness https://www.wikidata.org/wiki/Wikidata:Shelter When you are with friends you don't need to put any rule or condition, because they are people you like to be with. If each one does a little effort to become someone who everybody likes to be with, then all harshness will disappear and Wikidata will become even more wonderful \o/ And even if we don't reach utopia tomorrow, at least we'll be on the right direction :) I would like to invite everyone to participate in this initiative and to come up with new ways to reduce conflict before it happens. Very nice. Thanks for taking the initiative. In general, I already find Wikidata a great, friendly community to work with, but it is better to cement this now to be sure it stays this way :-) After all, friendliness can always be improved in online communication (already by remembering that some people are more sensitive than others to the tone of an email ;-). I think we are already doing very well on encouragement and openness, but again it's important to keep this up. Best wishes, Markus ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] New initiative to promote friendliness
Exactly! That's the spirit, it is much better to cement openess and tolerance while they are there :) And just by setting up that page we'll have a place to chill out :) Thanks Micru On Fri, Jul 25, 2014 at 5:12 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 25/07/14 15:28, David Cuenca wrote: Worried about the harshness that lately has been developing, I have started a new initiative to counter that by promoting more dialogue, civility, and friendliness https://www.wikidata.org/wiki/Wikidata:Shelter When you are with friends you don't need to put any rule or condition, because they are people you like to be with. If each one does a little effort to become someone who everybody likes to be with, then all harshness will disappear and Wikidata will become even more wonderful \o/ And even if we don't reach utopia tomorrow, at least we'll be on the right direction :) I would like to invite everyone to participate in this initiative and to come up with new ways to reduce conflict before it happens. Very nice. Thanks for taking the initiative. In general, I already find Wikidata a great, friendly community to work with, but it is better to cement this now to be sure it stays this way :-) After all, friendliness can always be improved in online communication (already by remembering that some people are more sensitive than others to the tone of an email ;-). I think we are already doing very well on encouragement and openness, but again it's important to keep this up. Best wishes, Markus ___ 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] Wikidata just got 10 times easier to use
I noticed that sometimes it is a bit sluggish when showing the suggestions, maybe it is my network, no idea. And it would be nice if it could suggest the three basic properties (instance of, sublcass of, part of) when the item is empty and suggest further properties based on that initial value, Other than that, good job! On Tue, Jul 1, 2014 at 10:00 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Tue, Jul 1, 2014 at 9:52 PM, Derric Atzrott datzr...@alizeepathology.com wrote: We still need to tweak it a bit here and there, yeah. We're working on that right now. Also it will get smarter as more statements are added to items. Even with some somewhat off suggestions this will be a wonderful tool. \o/ We've just changed the threshold a bit so it should give less but more fitting suggestions. We'll play around with that setting a bit more over the next days to find the one that's right for us. Thank you to everyone who worked on making this happen! This really is going to make Wikidata so much easier to use. Is there any documentation on how it chooses which entities to suggest? It basically creates a table of correlations for properties over all items in Wikidata. So if say date of birth and place of birth are used together a lot they get a high correlation. When you then have an item with no place of birth but a date of birth it will suggest that because of the high correlation. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata just got 10 times easier to use
Markus, could your algorithm work together with human direction? Like, if we entered which properties are common for a class, and then a user creates an instance of that class, would the algorithm be able to sort those properties based on how often they appear on the database? Thanks, Micru On Tue, Jul 1, 2014 at 10:23 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 01/07/14 22:14, Markus Krötzsch wrote: ... (2) Grade I listed building http://tools.wmflabs.org/wikidata-exports/miga/?classes#_cat=Classes/Id= Q15700818 Related properties: English Heritage list number, masts, Minor Planet Center observatory code, home port, coordinate location, OS grid reference, mother house, architect, manager/director, Emporis ID, MusicBrainz place ID, country, architectural style, visitors per year, Commons category, Structurae ID (structure), officially opened by, floors above ground, inspired by, religious order, number of platforms, street, owned by, diocese These are computed fully automatically from the data, with no manual filtering or user input. But don't get me wrong -- great work! Brilliant to have such a thing integrated into the UI. In any case, my algorithm for computing the related properties is certainly very different from theirs; I am sure it also has its glitches. P.S. One weakness of my algorithm you can already see: it has troubles estimating the relevance of very rare properties, such as Minor Planet Center observatory code above. A single wrong annotation may then lead to wrong suggestions. Also, it seems from my list under (2) that some Grade I listed buildings are ships. This seems to be an error that is amplified by the fact that property masts is used only 11 times in the dataset I evaluated (last week's data). I guess the new property suggester rather errs on the other side, being tricked into suggesting very frequent properties even in places that don't need them. -- Markus ___ 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] Monolingual text and old languages
Hi, Will the monolngual text datatype support old languages? There are settlements that had an official name in a now dead language. Besides of no language, will there be an option to mark such names as custom and use the qualifier language (p407) instead? Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Monolingual text and old languages
On Sun, Jun 29, 2014 at 3:01 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: This is correct. However, there will be no custom option: the set of languages supported by wikidata is a well-defined list, controlled by the configuration of the site. It's basically the list of languages MediaWiki supports for the user interface, plus a few special ones. Adding a language can be done based on community consensus. What about constructed or invented languages? A list will work for most cases but there always will be edge cases and adding them to the list will be too much. *Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.* Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Monolingual text and old languages
For instance in Template:Infobox fictional country there is a field for fictional mottos, like the one for Syldavia, the fictional country that appears in The Adventures of Tintin: Syldavia (Q1751922) motto Eih bennek, eih blavek. language Syldavian (Q2708019) On Sun, Jun 29, 2014 at 6:33 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey :) On Sun, Jun 29, 2014 at 3:08 PM, David Cuenca dacu...@gmail.com wrote: What about constructed or invented languages? A list will work for most cases but there always will be edge cases and adding them to the list will be too much. Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. Which languages are you worried about specifically? What kind of data would you want to record for them? (I'm trying to get a feeling for how large the problem is and which parts of it are already solved.) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] first draft for new user interface design
On Tue, Jun 17, 2014 at 10:50 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: I really don't want us to add this additional complexity at this point. We're trying really hard to make editing friendlier and easier to understand. I think this would go in the opposite direction. Not necessarily. It is just the same concept as statements, just in a different section. I have left a mockup on the ui page. Let's move the discussion to https://www.wikidata.org/wiki/Wikidata:UI_redesign_input please. Ok! :-) Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] first draft for new user interface design
Considering how hard is to please everyone I think it is a good start. The color scheme is much better than the omg-this-is-so-depressing grey that we have right now. And the picture plus the boxes look like they have the right size. I'm not so sure about the statements size, but if they can be shown collapsed, ok. As Thomas I also miss a collection of all references in a box on the right that could be drag and dropped on any item. And some sorting options, like alphabetical, by property number, or some other basic property sorting (metadata properties on top). The only thing I'm not convinced about is the edition of label/alias statements. Labels/aliases should be edited as statements so we can have more variety and add qualifiers and references to them. Micru On Mon, Jun 16, 2014 at 10:37 PM, Thomas Douillard thomas.douill...@gmail.com wrote: Interesting. My first feeling is for references cloning : I had in mind some kind of boxes like the one on the left collumn to collect statements references, that could be drag and dropped or copy paste to statements to add reference to them. 2014-06-16 22:01 GMT+02:00 Lydia Pintscher lydia.pintsc...@wikimedia.de: Hey folks :) I just uploaded the first drafts for the new user interface design: https://www.wikidata.org/wiki/Wikidata:UI_redesign_input It's not finished yet but I wanted to hear what you're thinking about the direction we're going. Please leave any feedback you have on that page so we can keep it all in one place. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 ___ 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] RFC about part of
This RFC was pending after several discussions. How to clarify the property part of? https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Refining_%22part_of%22 Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata query feature: status and plans
Gerard, Normally users don't want information about human settlements, but about municipalities, which may contain several human settlements. Ideally we should have both and let the user decide what to look for. Thanks, Micru On Tue, Jun 10, 2014 at 11:08 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, As far as I am concerned, it is relevant to compare settlements in whatever country they are. A British city is always located in the United Kingdom and even more precise it is in the administrative unit of a county or whatever. When it is a city for historical reasons, this can be indicated with a qualifier. In this way it is is a settlement and the rest can be deduced. Having specific types of settlements for countries is imho not necessary in this way. Thanks, GerardM On 10 June 2014 22:14, David Cuenca dacu...@gmail.com wrote: Hi Gerard, I think we should not aim for a perfect system, just for a better one. In our case we don't need to reproduce all cases, just identify the most relevant ones and to clarify when to use each and label/describe them clearly. Part of is understood, but in so many possible ways that its meaning gets diluted into uselessness. Thanks, Micru On Tue, Jun 10, 2014 at 9:50 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I fear that when words like mereology are expected to be understood, we will fall into the trap where our communities fear what we have been sniffing. It will just alienate them. Part of is something that is understood. There may be academic reasons that make sense to the people who care about them. The question I think we should take serious is if that is really where we want to go. Thanks, GerardM On 10 June 2014 20:21, David Cuenca dacu...@gmail.com wrote: I think we should drop part of and start using a better mereological system https://en.wikipedia.org/wiki/Mereology#Various_systems http://plato.stanford.edu/entries/mereology/image1.png Cheers, Micru On Tue, Jun 10, 2014 at 8:05 PM, Joe Filceolaire filceola...@gmail.com wrote: Even where there is complete agreement that a human settlement is a 'city' there is still usually a question over the population of that city. The question is down to what to include. A city in many cases is understood to include the contiguous built up area but this will often extend far beyond the original administrative region that bears the name. So we have the City of London (the central business district, corresponding to the medieval and Roman city), Greater London (The collection of contiguous urban boroughs that area part of the Greater London administrative entity - ironically this does not include the City of London but does include the City of Westminster), all the built up areas out to the Metropolitan green belt (includes bits of every county adjacent to Greater London), or all areas within commuting distance of Central London (with the train services this includes a lot of area and it is getting bigger as faster trains are deployed). When do two cities become one? London and Westminster? Buda and Pest? Minneapolis and St Paul? Dallas and Fort Worth? Kansas MI and Kansas KA? Dusseldorf, Essen and Dortmund? Detroit and Windsor? Joe On Tue, Jun 10, 2014 at 12:50 PM, Andrew Gray andrew.g...@dunelm.org.uk wrote: On 10 June 2014 09:20, Markus Krötzsch mar...@semantic-mediawiki.org wrote: The class city is used for relatively large and permanent human settlement[s] [1], which does not say much (because the vagueness of relatively). Maybe we should even wonder if city is a good class to use in Wikidata. Saying that something has been awarded city status in the UK (Q1867820) has a clear meaning. Saying that something is a human settlement is also rather clear. But drawing the line between village, city and town is quite tricky, and will probably never be done uniformly across the data. Conclusion: if you are looking for, say, human settlements with more than 100k inhabitants, then you should be searching for just that (which I think is basically what you also are saying below :-). OSM has had a lot of problems with this as well, I think - labelling something as a city is one of those very slippery terms that everyone thinks is obvious but never quite agrees on what the obvious bit is :-) I wonder if we should think about how best to make sure people know this. Perhaps there is a role for the human-readable pages to have disambiguation-type notes on them? If you are aiming to do a search based on instances of 'city', we recommend you try instances of 'human settlement' instead... -- - Andrew Gray andrew.g...@dunelm.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing
Re: [Wikidata-l] Wikidata query feature: status and plans
I think we should drop part of and start using a better mereological system https://en.wikipedia.org/wiki/Mereology#Various_systems http://plato.stanford.edu/entries/mereology/image1.png Cheers, Micru On Tue, Jun 10, 2014 at 8:05 PM, Joe Filceolaire filceola...@gmail.com wrote: Even where there is complete agreement that a human settlement is a 'city' there is still usually a question over the population of that city. The question is down to what to include. A city in many cases is understood to include the contiguous built up area but this will often extend far beyond the original administrative region that bears the name. So we have the City of London (the central business district, corresponding to the medieval and Roman city), Greater London (The collection of contiguous urban boroughs that area part of the Greater London administrative entity - ironically this does not include the City of London but does include the City of Westminster), all the built up areas out to the Metropolitan green belt (includes bits of every county adjacent to Greater London), or all areas within commuting distance of Central London (with the train services this includes a lot of area and it is getting bigger as faster trains are deployed). When do two cities become one? London and Westminster? Buda and Pest? Minneapolis and St Paul? Dallas and Fort Worth? Kansas MI and Kansas KA? Dusseldorf, Essen and Dortmund? Detroit and Windsor? Joe On Tue, Jun 10, 2014 at 12:50 PM, Andrew Gray andrew.g...@dunelm.org.uk wrote: On 10 June 2014 09:20, Markus Krötzsch mar...@semantic-mediawiki.org wrote: The class city is used for relatively large and permanent human settlement[s] [1], which does not say much (because the vagueness of relatively). Maybe we should even wonder if city is a good class to use in Wikidata. Saying that something has been awarded city status in the UK (Q1867820) has a clear meaning. Saying that something is a human settlement is also rather clear. But drawing the line between village, city and town is quite tricky, and will probably never be done uniformly across the data. Conclusion: if you are looking for, say, human settlements with more than 100k inhabitants, then you should be searching for just that (which I think is basically what you also are saying below :-). OSM has had a lot of problems with this as well, I think - labelling something as a city is one of those very slippery terms that everyone thinks is obvious but never quite agrees on what the obvious bit is :-) I wonder if we should think about how best to make sure people know this. Perhaps there is a role for the human-readable pages to have disambiguation-type notes on them? If you are aiming to do a search based on instances of 'city', we recommend you try instances of 'human settlement' instead... -- - Andrew Gray andrew.g...@dunelm.org.uk ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata query feature: status and plans
Hi Gerard, I think we should not aim for a perfect system, just for a better one. In our case we don't need to reproduce all cases, just identify the most relevant ones and to clarify when to use each and label/describe them clearly. Part of is understood, but in so many possible ways that its meaning gets diluted into uselessness. Thanks, Micru On Tue, Jun 10, 2014 at 9:50 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I fear that when words like mereology are expected to be understood, we will fall into the trap where our communities fear what we have been sniffing. It will just alienate them. Part of is something that is understood. There may be academic reasons that make sense to the people who care about them. The question I think we should take serious is if that is really where we want to go. Thanks, GerardM On 10 June 2014 20:21, David Cuenca dacu...@gmail.com wrote: I think we should drop part of and start using a better mereological system https://en.wikipedia.org/wiki/Mereology#Various_systems http://plato.stanford.edu/entries/mereology/image1.png Cheers, Micru On Tue, Jun 10, 2014 at 8:05 PM, Joe Filceolaire filceola...@gmail.com wrote: Even where there is complete agreement that a human settlement is a 'city' there is still usually a question over the population of that city. The question is down to what to include. A city in many cases is understood to include the contiguous built up area but this will often extend far beyond the original administrative region that bears the name. So we have the City of London (the central business district, corresponding to the medieval and Roman city), Greater London (The collection of contiguous urban boroughs that area part of the Greater London administrative entity - ironically this does not include the City of London but does include the City of Westminster), all the built up areas out to the Metropolitan green belt (includes bits of every county adjacent to Greater London), or all areas within commuting distance of Central London (with the train services this includes a lot of area and it is getting bigger as faster trains are deployed). When do two cities become one? London and Westminster? Buda and Pest? Minneapolis and St Paul? Dallas and Fort Worth? Kansas MI and Kansas KA? Dusseldorf, Essen and Dortmund? Detroit and Windsor? Joe On Tue, Jun 10, 2014 at 12:50 PM, Andrew Gray andrew.g...@dunelm.org.uk wrote: On 10 June 2014 09:20, Markus Krötzsch mar...@semantic-mediawiki.org wrote: The class city is used for relatively large and permanent human settlement[s] [1], which does not say much (because the vagueness of relatively). Maybe we should even wonder if city is a good class to use in Wikidata. Saying that something has been awarded city status in the UK (Q1867820) has a clear meaning. Saying that something is a human settlement is also rather clear. But drawing the line between village, city and town is quite tricky, and will probably never be done uniformly across the data. Conclusion: if you are looking for, say, human settlements with more than 100k inhabitants, then you should be searching for just that (which I think is basically what you also are saying below :-). OSM has had a lot of problems with this as well, I think - labelling something as a city is one of those very slippery terms that everyone thinks is obvious but never quite agrees on what the obvious bit is :-) I wonder if we should think about how best to make sure people know this. Perhaps there is a role for the human-readable pages to have disambiguation-type notes on them? If you are aiming to do a search based on instances of 'city', we recommend you try instances of 'human settlement' instead... -- - Andrew Gray andrew.g...@dunelm.org.uk ___ 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 -- 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of labels?
Other possibilities (not necessarily all together): - new datatype label, with the value to be indexed as an alias - use qualifiers on label statements to add lexical data or to link with declination tables - consider labels internally as independent items, but don't display them as such On Thu, Jun 5, 2014 at 4:28 PM, David Cuenca dacu...@gmail.com wrote: When I drafted the functional structure that is appearing on items [1], Gerard pointed out that it is drifting into the lexical area. That made me think that while useful to have lexical data as an independent item as we discussed last year for Wiktionary, the current structure q item label string doesn't seem to be compatible with that wish, or at least it would be more difficult to maintain the same label twice. And it is not just one label per item, there are many, and each one might have different lexical properties. For more efficiency, it seems that we would need statements like q item label lexical item to reflect that separation, but that adds further complexity, because according to the latest Wikidata:Wiktionary proposal [2], the lexical item (W) also contains senses/meanings (S). This is recurrent, as we already have Q items as the basis for meaning... or at least a concept that is more or less shared among languages. The only difference between Q items and the proposed S items is that S items represent only one of the lexeme meanings for one particular language, but other than that they have the same nature as Q items (it should be possible to add subclass of and other statements to them). Labels, aliases, and name properties are just normal statements where one of them is preferred, I have been wondering why don't we treat them as such... That way we could have some coherence, and have both Q items and S items as the units of meaning/sense and later on move the labels (lexemes), which now are strings, to the lexical items (W items in the example on the page Wikidata:Wiktionary). Summing up, labels in their current form make complete sense now, but when considered together with lexical information, it seems that it would be convenient to treat all of them as statements that later on could link with W items. And as Joe pointed out, there are many more properties that are equivalent to a label, just more specific, and that now don't show up in the suggester, nor up above of the page where they should. I know that Wiktionary is still in the future and that there are many other priorities on the way, however since the representation of the items is being re-considered, I think it is a good moment to think about how to move little by little in the right direction. I also would like to point out that by keeping lexical information in wikidata, its complexity is going to increase inevitably. If new users already struggling to understand it now, I cannot imagine how will they cope with added elements... Micru [1] http://lists.wikimedia.org/pipermail/wikidata-l/2014-June/003941.html [2] https://www.wikidata.org/wiki/Wikidata:Wiktionary -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of labels?
On Fri, Jun 6, 2014 at 3:08 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: SKOS is a good fit for Wikidata data items. For modeling Wiktionary, LEMON fits a lot better http://lemon-model.net/. Could you please elaborate on how to share the label between q items and the future lexical items? It is not very clear to me what you have in mind. OTOH, is there any possibility to have some property values indexed as aliases? (like the ones Joe mentioned [1]: birth name, pseudonym) Thanks Micru [1] http://lists.wikimedia.org/pipermail/wikidata-l/2014-June/003944.html ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of labels?
On Fri, Jun 6, 2014 at 5:05 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: The software shouldn't know about special properties. A bot could know about them, and automatically add aliases. Labels and aliases are acting as special properties, just that we cannot decide which property to use instead of the default. Now we have to enter twice the property, for instance title and again as label title, same for names, same for official names of towns, same for everything... and even more so when the monolingual datatype is available. Yes, a bot could do that, but perhaps we should ask ourselves if to have all information twice makes sense? Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of labels?
On Fri, Jun 6, 2014 at 7:08 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: It's really too early to make all these decisions. We're still at least a year away from any significant progress towards Wiktionary unless anything changes. Until then we will have learned a lot more and a lot of things will have changed. Let's focus on the next big things and not lose focus: queries and Commons support :) Ah, don't worry Daniel's answer regarding future W item connection was enough concerning Wiktionary. I also want to see queries and Commons support soon :-) My main motivation to start this discussion was linked with the planned UI revamp. That is what the user sees and it conveys meaning, and not only that, users learn it and get attached to it. If there is any change to be made to labels/aliases it would be better to do it before, and to plan the mockups with those changes in mind. I remember that you mentioned that external identifier statements should appear in another area of the screen? I don't know which mechanism would be used to accomplish that, but maybe it would help if the same method is applied to properties that represent a label? Just giving ideas, I have no preference, actually everything would be better than having to maintain (repeated) aliases by bot :) Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Item metadata
On Thu, Jun 5, 2014 at 3:15 PM, Joe Filceolaire filceola...@gmail.com wrote: Note that 'historic name' is not among these. Historic name is just an official name (or one of the other name types) with an 'end date' qualifier. These names are, I believe, worth putting in statements so we can qualify the statements with dates, type of name, language, references etc. The label and aliases are merely search terms and should, I believe, include all of the names above plus common misspellings. Thanks, Joe, for clearing this up. It didn't occur to me that there are so many! And now that I think of it, there are more subclasses of label, like title or original title. I have been thinking about how this connects with lexical information, perhaps it is better to start a separate thread, since the title of this one is misleading. Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Item metadata
In order to clarify my previous email I have prepared this functional taxonomy of the elements that in my opinion form an item: Meta + Labels -- Multilingual main label (no sources, no qualifiers) -- Multilingual alternative labels (no sources, no qualifiers) -- Multilingual historic/alternative labels (will be possible with monolingual datatype+qualifiers) -- External identifiers (currently treated as statements) -- Sitelinks (how each project calls the concept) + Metainformation -- Concept taxonomy (part of/ subclass of) -- Concept life-cycle (sometimes irrelevant, other times expressed with start/end date, no deprecation possible) -- Concept precedence (possible to express as statements succeeded by/preceded by, but perhaps needs disambiguation from content) -- Concept dependence (endemic to, bound to [experience/cognition/etc], recognition methods, etc) -- Source for the concept (not defined, sometimes irrelevant) Content + Current information -- Statements + Historic information -- Deprecated statements + Open data information -- Related to outcome on RFC about open datasets ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Item metadata
Interesting appreciation... I didn't draft it with lexical information in mind. If we are struggling to make it different, perhaps there is no difference? Thanks, Micru On Wed, Jun 4, 2014 at 3:55 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Nice. However, it is not something we can cope with at this time. It makes sense to first be able to include lexical items because what you are getting into is firmly in that area. Thanks, GerardM On 3 June 2014 20:30, David Cuenca dacu...@gmail.com wrote: Continuing with the discussion of last week about the nature of properties I follow with my personal crusade to foster a better understanding of Wikidata (which sometimes means asking difficult questions :)). This time I ask about items, or concepts for that matter. To start with I cherry-pick a very insightful question posed by Markus last week, that unfortunately I left unanswered: The main question is Did the reference say that pianos are instruments? but not Did the reference say pianos are instruments because of the definition of 'piano'? Therefore, we don't need to put this information in our labels. To my mind that is a problem that, as the chicken and the egg, can be settled with just a word: emergence. There is no such thing as a piano or a concept of a piano. But both of them, concept and object, co-evolved over time and now we recognize certain objects as pianos. Timeline: https://en.wikipedia.org/wiki/Piano#History There have been so many innovations upon innovations, versions, and even name changes, that what we call now piano is very different from what it was long ago. Same can be said about other concepts like country of citizenship, which is not a valid concept when talking about historic people. When we are creating an item we are capturing a moment of time of the past, according to a source in a different past. Eventually this item might change its label, change its meaning, or become obsolete. So when I look in Wikidata for: - a way to reflect label changes over time: yes, that will be possible with the mono-lingual datatype + qualifiers, creating a property label - a way to reflect that the concept is obsolete: perhaps it could be reflected with start/end date - a way to indicate a different item with a related meaning: it can be done with properties This information is not about the item itself, but we treat it as other statements. In my opinion these kind of statements are different (as labels, or descriptions), since they don't refer to the represented entity, but to the container that represents the entity. Like the walls of a bubble. I can imagine that there will be some confusion between labels that can accept qualifiers, other than don't, and aliases that can edited in one language but not in other, and all this not grouped with other statements that belong to the same metadata group. So I candidly ask: does it make sense to treat item metadata statements just as any other statement? Would it bring more confusion or less? Cheers, Micru ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Item metadata
Continuing with the discussion of last week about the nature of properties I follow with my personal crusade to foster a better understanding of Wikidata (which sometimes means asking difficult questions :)). This time I ask about items, or concepts for that matter. To start with I cherry-pick a very insightful question posed by Markus last week, that unfortunately I left unanswered: The main question is Did the reference say that pianos are instruments? but not Did the reference say pianos are instruments because of the definition of 'piano'? Therefore, we don't need to put this information in our labels. To my mind that is a problem that, as the chicken and the egg, can be settled with just a word: emergence. There is no such thing as a piano or a concept of a piano. But both of them, concept and object, co-evolved over time and now we recognize certain objects as pianos. Timeline: https://en.wikipedia.org/wiki/Piano#History There have been so many innovations upon innovations, versions, and even name changes, that what we call now piano is very different from what it was long ago. Same can be said about other concepts like country of citizenship, which is not a valid concept when talking about historic people. When we are creating an item we are capturing a moment of time of the past, according to a source in a different past. Eventually this item might change its label, change its meaning, or become obsolete. So when I look in Wikidata for: - a way to reflect label changes over time: yes, that will be possible with the mono-lingual datatype + qualifiers, creating a property label - a way to reflect that the concept is obsolete: perhaps it could be reflected with start/end date - a way to indicate a different item with a related meaning: it can be done with properties This information is not about the item itself, but we treat it as other statements. In my opinion these kind of statements are different (as labels, or descriptions), since they don't refer to the represented entity, but to the container that represents the entity. Like the walls of a bubble. I can imagine that there will be some confusion between labels that can accept qualifiers, other than don't, and aliases that can edited in one language but not in other, and all this not grouped with other statements that belong to the same metadata group. So I candidly ask: does it make sense to treat item metadata statements just as any other statement? Would it bring more confusion or less? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of properties?
On Thu, May 29, 2014 at 9:04 PM, Andrew Gray andrew.g...@dunelm.org.uk wrote: One other issue to bear in mind: it's *simple* to have properties as a separate thing. I have been following this discussion with some interest but... well, I don't think I'm particularly stupid, but most of it is completely above my head. Saying here are items, here are a set of properties you can define relating to them, here's some notes on how to use properties is going to get a lot more people able to contribute than if they need to start understanding theoretical aspects of semantic relationships... Definitely, I cannot agree more. TBH, the original question of this thread was already settled some messages ago. I understand that it might result confusing that we have wandered off into other realms, so I consider that it is better to consider this thread closed and I will consider opening a new one with the right topic (which is quite different as it started :-P) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of properties?
And to summarize the answer of the original question to future readers. The point of properties is: a) to help humans to better understand Wikidata b) to help programmers (also humans :P) build the software running it c) to make a distinction between concepts found in the world and the concepts that have been interiorized by the community There might be more, but those are the main points that suggest that it is better to keep properties and items separate even if their essence is the same. Thank you all for this learning experience :-) Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] What is the point of properties?
Since the very beginning I have kept myself busy with properties, thinking about which ones fit, which ones are missing to better describe reality, how integrate into the ones that we have. The thing is that the more I work with them, the less difference I see with normal items and if soon there will be statements allowed in property pages, the difference will blur even more. I can understand that from the software development point of view it might make sense to have a clear difference. Or for the community to get a deeper understanding of the underlying concepts represented by words. But semantically I see no difference between: cement (Q45190) emissivity (P1295) 0.54 and cement (Q45190) emissivity (Q899670) 0.54 Am I missing something here? Are properties really needed or are we adding unnecessary artificial constraints? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of properties?
On Wed, May 28, 2014 at 10:37 AM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: More fundamentally, they are semantically different: an item describes a concept in the real world, while a property is a structural component used for such a description. As I perceive it, a property is a normal item (concept) imbued with the option to use it as predicate and allow it to use different datatypes. There is no property that cannot be expressed as an item, even properties that represent an identifier, they also could be said that they are a concept in the real world. I understand that from the software side you need to make a difference between basic concepts (items) and concepts that can be used as predicates (properties). From the community side we also need to scrutinize and rinse the concepts that hide behind the words before using them as predicates, but sometimes it is good to stop and consider what are we really doing. Yes, properies are simmilar to data items, and in some cases, there may be an item representing the same concept that is represented by a property entity. I haven't found yet a property that couldn't be expressed as an item. I don't see why that is a problem, while I can see a lot of confusion arising from mixing them. It is not a problem now but I considered interesting to analyze what is the substance of the distinction. If properties and concepts are separate in the end we will be reproducing their ontological structure when organizing them. So then it might not make sense to use subproperty of to organize properties, but just corresponds to item. Gerard, thanks for bringing the example of OmegaWiki, it is interesting that two independent communities came to the same thoughts without any contact between them :) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of properties?
still have items and properties share a page and somehow define which statements/claims refer to which concept, but this does not seem to make things easier for users. These are, for me, the two main reasons why it makes sense to keep properties apart from items on a technical level. Besides this, it is also convenient to separate the 1000-something properties from the 15-million something items for reasons of maintenance. Best regards, Markus On 28/05/14 09:25, David Cuenca wrote: Since the very beginning I have kept myself busy with properties, thinking about which ones fit, which ones are missing to better describe reality, how integrate into the ones that we have. The thing is that the more I work with them, the less difference I see with normal items and if soon there will be statements allowed in property pages, the difference will blur even more. I can understand that from the software development point of view it might make sense to have a clear difference. Or for the community to get a deeper understanding of the underlying concepts represented by words. But semantically I see no difference between: cement (Q45190) emissivity (P1295) 0.54 and cement (Q45190) emissivity (Q899670) 0.54 Am I missing something here? Are properties really needed or are we adding unnecessary artificial constraints? Cheers, Micru ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] What is the point of properties?
Markus, Ok, now I understand that same as wouldn't be a good name for the confusion it would cause. However the property subject of as it is now wouldn't be a good candidate either. Its meaning is that a certain statement is represented by another item (that is why it is only allowed to be used as qualifier). Perhaps a better name would be corresponds with item and the inverse corresponds with property. Just by having these connections, a lot of information can be inferred from the connected item. Consider the following example with occupation (P106), and occupation (Q13516667): - I cannot find any clear subproperty of for p106, but there is a clear subclass of:human behaviour for the item - human behaviour is part of human - human can have a statement intrinsic property (property proposal still under discussion) with values birthday (Q47223) and an (eventual) date of death. It can be expanded in the future to include newly created properties like height, weight, eye color, etc - birthday (Q47223) corresponds with property date of birth (P569) Out of this I reach the following conclusions: - the taxonomy of properties is going to be weak, since there is not always a clear subpropertyOf unless created artificially (more work) - the standard taxonomy of items (subclass of/part of) is sufficient to automatically reach meaningful constraints and inference (less work) - by adding manually the constraints to the property itself we are duplicating information which will require volunteer effort to maintain (more work) My recommendation is to rely mainly on the main taxonomy instead of creating a parallel property taxonomy, and then think of ways to extract information from the main taxonomy to convert it automatically into constraints. All the maintenance takes effort, so the more it can be automated, the more efficient volunteers will be. And if we can simplify the maintenance of properties, we will be able to simplify the creation of properties too, specially when we face the next surge which will come with the datatype number with units. Cheers, Micru On Wed, May 28, 2014 at 2:48 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: David, Regarding the question of how to classify properties and how to relate them to items: * same as (in the sense of owl:sameAs) is not the right concept here. In fact, it has often been discouraged to use this on the Web, since it has very strong implications: it means that in all uses of the one identifier, one could just as well use the other identifier, and that it is indistinguishable if something has been said about the one or the other. That seems too strong here, at least for most cases. * In the world of OWL DL, sameAs specifically refers to individuals, not to classes or properties. Saying P sameAs Q does not imply that P and Q have the same extension as properties. For the latter, OWL has the relationship owl:equivalentProperties. This distinction of instance level and schema level is similar to the distinction we have between instance of and subclass of. * Therefore, I would suggest to use a property called subproperty of as one way of relating properties (analogously to subclass of). It has to be checked if this actually occurs in Wikidata (do we have any properties that would be in this relation, or do we make it a modelling principle to have only the most specific properties in Wikidata?). * The relationship from properties to items could be modelled with the existing property subject of (P805). * It might be useful to also have a taxonomic classification of properties. For example, we already group properties into properties for people, organisations, etc. Such information could also be added with a specific property (this would be a bit more like a category system on property pages). On the other hand, some of this might coincide with constraint information that could be expressed as claims. For instance, person properties might be those with Type (i.e., rdfs:domain) constraint human. By the way, our constraint system could use some systematisation -- there are many overlaps in what you can do with one constraint or another. Cheers, Markus On 28/05/14 12:14, David Cuenca wrote: Markus, The explanation about the implications of renaming/deleting makes most sense and just that justifies already the separation in two. It is equally true that when we create a property, we might have cleaned the original concept so much that it might differ (even slightly) with the understood concept that the item represents. However, even after that process, the new concept is still an item... The process of imbuing a concept with permanent characteristics (adding a datatype) and the practical approach, also seems to recommend keeping items and properties separate. Thanks for showing me that reasoning :) I am still wondering about how are we going to classify properties. Maybe it will require a broader
Re: [Wikidata-l] What is the point of properties?
Markus, I share your dissatisfaction with part of because that language construct hides many different conceptual relationships that should be cleared out, I think we'll have some community discussion work to do in that regard. One of the uses is: what is the relationship between a human and his behavior? I would say that the human has been defined as having human behavior (or the reverse). But if you have a better suggestion to express this concept I would be really glad to hear it. Now that you mention it, yes, I agree that only a property called corresponds with item makes sense in this context, but not the inverse. I would like to make a further distinction regarding constraints. The nature of constraints is not to set arbitrary limits but to reflect patterns that naturally appear in concepts. On that regard, I hate the word constraint, because it means that we are placing a straitjacket on reality, when it is the other way round, recurring patterns in the real world make us expect that a value will fall within the bonds of our expectations. I think that we should seriously consider using the term expectation from now on because we don't constrain the values per se, we expect them to have a value, and when the value departs from the expected value, then it sets an alarm that might reflect an error or not. Once made that distinction, yes, you are right, considering that we are separating properties and items, our expectations do not belong to the data itself, they belong to the property. However, I would like to go to bring the conversation to a deeper level. What is that what makes the concept of addition (Q32043) to be that? What is in physical object (Q223557) that we, sentient beings, can perceive and agree to treat as a concept? I mention those two because one is purely abstract, and the other one is purely physical. And I would say that addition (Q32043) has been defined as having associativity (Q177251) and physical object (Q223557) has been repeatedly observed to have density (Q29539). We can argue whether the second is an expectation or not, but the first is definitely not, someone defined an addition like that and this information can be sourced. Even more, we could also say that also physical object (Q223557) has been defined as having density (Q29539), and I guess we could find sources for that statement too. With all this I want to make the point that there are two sources of expectations: - from our experience seeing repetitions and patterns in the values (male/female/etc between 10 and 50), which belong to the property - from the agreed definition of the concept itself, which belong to the data Cheers, Micru PS: this is a re-post because my previous message was bounced back for being too long :) ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Using external vocabularies (like RDA) in WikiData ?
Hello Jean-Baptiste and welcome! regarding the bibliographic aspects of your question, I have to mention that we have a page where we collect and discuss these properties https://www.wikidata.org/wiki/Wikidata:Books_task_force As you can see, we already use the FRBR model and we were considering mapping external ontologies like FaBiO or others https://www.wikidata.org/wiki/Wikidata_talk:Books_task_force#Mapping_external_ontologies But of course we are always short on volunteers and this is not done yet, so if you would like to help out finding equivalences with RDA or/and FaBiO we would be most grateful. What needs to be done is to find out where are the exact relationships and where we use a different way to express the same concept, and if we miss any property, then propose it for creation. That could be a previous step before the connection can be established directly from the property page, as Daniel mentioned. Cheers, Micru On Wed, May 28, 2014 at 3:05 PM, Jean-Baptiste Pressac jean-baptiste.pres...@univ-brest.fr wrote: 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 FRBRhttp://www.ifla.org/publications/functional-requirements-for-bibliographic-recordsconceptual 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 ___ 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] What is the point of properties?
Markus, On Thu, May 29, 2014 at 12:53 AM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: This is an easy question once you have been clear about what human behaviour is. According to enwiki, it is a range of behaviours *exhibited by* humans. Settled :) Let's leave it at defined as a trait of What would anybody do with this data? In what application could it be of interest? Well, our goal it to gather the whole human knowledge, not to use it. I can think of several applications, but let's leave that open. Never underestimate human creativity ;-) Moreover, as a great Icelandic ontologist once said: There is definitely, definitely, definitely no logic, to human behaviour ;-) Definitely, that is why we spend so much time in front of flickering squares making them flicker even more. It makes total sense :P I think constraints are already understood in this way. The name comes from databases, where a constraint violation is indeed a rather hard error. On the other hand, ironically, constraints (as a technical term) are often considered to be a softer form of modelling than (onto)logical axioms: a constraint can be violated while a logical axiom (as the name suggests) is always true -- if it is not backed by the given data, new data will be inferred. So as a technical term, constraint is quite appropriate for the mechanism we have, although it may not be the best term to clarify the intention. Ok, I will not fight traditional labels nor conventions. I was interested in pointing out to the inappropriateness of using a word inside our community with a definition that doesn't matches its use, when there is another word that matches perfectly and conveys its meaning better to users. Some important ideas like classification (instance of/subclass of) belong completely to the analytical realm. We don't observe classes, we define them. A planet is what we call a planet, and this can change even if the actual lumps in space are pretty much the same. Agreed. Better labels could be defined as instance of/defined as subclass of Now inferences are slightly different. If we know that X implies Y, then if A says X we can infer that (implicitly) A says Y. That is a logical relationship (or rule) on the level of what is claimed, rather than on the level of statements. Note that we still need to have a way to find out that X implies Y, which is a content-level claim that should have its own reference somewhere. We mainly use inference in this sense with subclass of in reasonator or when checking constraints. In this case, the implications are encoded as subclass-of statements (If X is a piano, then X is an instrument). This allows us to have references on the implications. Nope, nope, nope. I was not referring to hard implications, but to heuristic ones. Consider that these properties in the item namespace: defined as a trait of defined as having defined as instance of Would translate as these constraints in the property namespace: likely to be a trait of likely to have likely to be an instance of In general, an interesting question here is what the status of subclass of really is. Do we gather this information from external sources (surely there must be a book that tells us that pianos are instruments) or do we as a community define this for Wikidata (surely, the overall hierarchy we get is hardly the universal class hierarchy of the world but a very specific classification that is different from other classifications that may exist elsewhere)? Best not to think about it too much and to gather sources whenever we have them ;-) I think it is good to think about it and to consider options to deal with it. Like for instance: defined as instance of corresponds with item Wikimedia community concept We already have items that refer to concepts that only make sense for us, so no change in that regard. At the moment, hard constraints (from definitions) and soft constraints (expectations) are simply mixed, and maybe this is fine since we handle them in a similar fashion (humans need to look how to fix the situation). Most constraints, even those that refer to definitions, are rather soft anyway since we apply them to statements, not to hard facts. Hard constraints can only occur in cases where the *encoding* of a statement in Wikidata is wrong (not the intended statement as such, but how it was translated to data). As explained above, expectations inferred from definitions should not be treated as hard constraints, but as soft ones. Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Tables
Please, leave your comments here too: https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets I've been gathering comments from several people, and in the next days I will try to summarize these suggestions to be discussed on irc. Thanks, Micru On Tue, May 27, 2014 at 2:12 PM, Ilario Valdelli valde...@gmail.com wrote: I am not an expert of Wikidata but I work a lot in integration of databases with several middlewares or tools. I think that the best way is to ask a solution to store and to download data in a format compatible with datasheets like CSV. Excel is considered also a tool to do some basic analysis, but it can be connected easily to a data source (if well structured). Excel itself is not a good approach to store data, so it's not a good solution to keep the data in excel format in a database. Doesn't make sense to store a 2D tables in a database in my opinion because the data have no sense and they are not helpful to anyone. They can be stored like a text file, but I would not imagine the series of errors that can be generated importing these data again. Regards On Tue, May 27, 2014 at 1:15 PM, Jan Kučera kozuc...@gmail.com wrote: Hi there, can tables be stored within wikidata database? I mean simple 2D tables like excel spreadsheets... Jan ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Ilario Valdelli Wikimedia CH Verein zur Förderung Freien Wissens Association pour l’avancement des connaissances libre Associazione per il sostegno alla conoscenza libera Switzerland - 8008 Zürich Wikipedia: Ilario https://meta.wikimedia.org/wiki/User:Ilario Facebook: Ilario Valdelli https://www.facebook.com/ivaldelli Twitter: Ilario Valdelli https://twitter.com/ilariovaldelli Linkedin: Ilario Valdellihttp://www.linkedin.com/profile/view?id=6724469 Tel: +41764821371 http://www.wikimedia.ch ___ 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] Subclass of/instance of
On Thu, May 15, 2014 at 5:03 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: I applaud your comparison of inferencing with a form of decompression. I think this is a nice intuition (in fact, some people have researched semantic compression where one tries to reduce the size of a knowledge base by eliminating things that follow from the rest anyway). Markus, sorry the delay answering to this, I had to let the ideas grow for a while. I also like the idea of decompression, that is what makes your database of inferred data even more useful. There is a lot of data that can be inferred, and not just from following the relationships, but by computing. For instance population density which can be calculated from area and population, or aggregates of the population of each town in a district. Another source of inferred statements are wp categories. Most of them are very easily translatable into statements, and the other way round too. A place where to store and process these inferences would be most useful if WD is not the right place. You also say: Constraints are a great start. We should now ask how we could improve the management of constraints in the future, and which constraints we will have then. The first step will be having them as statements, then having them as queries, and finally automating their correction, either by semi-automatic tools, or with gamification. How to automatically transform a constraint into a game to solve the outliers it might be also an interesting topic. And of course, more far fetched, but nevertheless relevant is how to connect the property to a perceptual mechanism. About improving the reliability: yes, as wikidata grows bigger some statements become more important. There is something to be learnt about how neural nets work, specially strengthening most-used (or traveled, or accepted, or viewed) connections. Another process little understood now is the need to forget, or in wikidata terms auto-deprecate information that is no longer current. Not very relevant now, but something to keep in mind for the next years. Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Weekyl summary #110
John,
I appreciate that you prepare these summaries so diligently. If you
wouldn't do it I would miss so many important things.
Thank you!
Cheers,
Micru
On Sun, May 25, 2014 at 6:31 PM, John Lewis johnflewi...@gmail.com wrote:
Hey everyone,
Here is the latest weekly summary
Discussions[edithttps://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_05_24action=editsection=1
]
- Discussion about Draft
articleshttps://www.wikidata.org/wiki/Wikidata:Project_chat#What_do_do_with_Wikipedia:Draft_articles
Events
https://www.wikidata.org/wiki/Wikidata:Events/Press/Blogshttps://www.wikidata.org/wiki/Wikidata:Press_coverage
[edithttps://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_05_24action=editsection=2
]
- Wikidata office hour
loghttps://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-05-19
- Wikiconference USA http://wikiconferenceusa.org/ in New York on
May 30th and June 1st
Other Noteworthy
Stuff[edithttps://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_05_24action=editsection=3
]
- Editors may now include their ORCIDhttps://en.wikipedia.org/wiki/ORCID
identifiers
(and others, such as VIAF https://en.wikipedia.org/wiki/VIAF) on
their user pages, using the{{Authority
controlhttps://www.wikidata.org/wiki/Template:Authority_control
}} template. You can register for an ORCID at http://orcid.org
- Play the Wikidata Game https://tools.wmflabs.org/wikidata-game
Development[edithttps://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_05_24action=editsection=5
]
- jQuery 1.9 compatibility fixes
- More fixes for gadgets (authority control, preview gadget)
- Improve formatting and handling of snak formatting errors
- Continued working on monolingual text data type
- Continued making messages easier to understand
- Removed a bunch of unused code, interfaces and methods
See current sprint
itemshttps://bugzilla.wikimedia.org/buglist.cgi?list_id=218716resolution=---resolution=LATERresolution=DUPLICATEemailtype1=substringemailassigned_to1=1query_format=advancedbug_status=ASSIGNEDemail1=wikidata
for
what we’re working on next.
You can view the commits currently in review
herehttps://gerrit.wikimedia.org/r/#/q/(+project:mediawiki/extensions/Wikibase+OR+project:mediawiki/extensions/Diff+OR+project:mediawiki/extensions/DataValues+OR+project:mediawiki/extensions/WikibaseSolr+OR+project:mediawiki/extensions/Ask+OR+project:mediawiki/extensions/WikibaseQuery+OR+project:mediawiki/extensions/WikibaseDatabase+OR+project:mediawiki/extensions/WikibaseQueryEngine+OR+project:mediawiki/extensions/WikibaseDataModel+)+status:open,n,z
and
the ones that have been merged
herehttps://gerrit.wikimedia.org/r/#/q/(+project:mediawiki/extensions/Wikibase+OR+project:mediawiki/extensions/Diff+OR+project:mediawiki/extensions/DataValues+OR+project:mediawiki/extensions/WikibaseSolr+OR+project:mediawiki/extensions/Ask+OR+project:mediawiki/extensions/WikibaseQuery+OR+project:mediawiki/extensions/WikibaseDatabase+OR+project:mediawiki/extensions/WikibaseQueryEngine+OR+project:mediawiki/extensions/WikibaseDataModel+)+status:merged,n,z
.
You can see all open bugs related to Wikidata
herehttps://bugzilla.wikimedia.org/buglist.cgi?emailcc1=1list_id=151540resolution=---emailtype1=exactemailassigned_to1=1query_format=advancedemail1=wikidata-bugs%40lists.wikimedia.org
Monthly
Tasks[edithttps://www.wikidata.org/w/index.php?title=Wikidata:Status_updates/2014_05_24action=editsection=6
]
- Fix a format or content
violationhttps://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P512
for
the academic degree (P512)https://www.wikidata.org/wiki/Property:P512
property
- Hack on one of
thesehttps://bugzilla.wikimedia.org/buglist.cgi?keywords=need-volunteer%2C%20keywords_type=allwordsemailcc1=1resolution=---emailtype1=exactemailassigned_to1=1query_format=advancedemail1=wikidata-bugs%40lists.wikimedia.orglist_id=162515
.
- Help develop the next summary
here!https://www.wikidata.org/wiki/Wikidata:Status_updates/Next
- Contribute to a Showcase item
https://www.wikidata.org/wiki/Wikidata:Showcase
___
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] Request for comments: How to deal with open datasets?
Hi, During the Zürich Hackathon I met several people that looked for solutions about how to integrate external open datasets into our projects (mainly Wikipedia, Wikidata). Since Wikidata is not the right tool to manage them (reasons explained in the RFC as discussed during the Wikidata session), I have felt convenient to centralize the discussion about potential requirements, needs, and how to approach this new changing landscape that didn't exist a few years ago. You will find more details here https://meta.wikimedia.org/wiki/Requests_for_comment/How_to_deal_with_open_datasets Your comments, thoughts and ideas are appreciated! Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikitech-l] [Wikimedia-l] Request for comments: How to deal with open datasets?
On Thu, May 15, 2014 at 1:42 PM, Cristian Consonni kikkocrist...@gmail.com wrote: Thanks for the pointer, How can I put this open data on Wikidata is a question that I have been asked many times, this page was needed. Thanks for your comment! On Thu, May 15, 2014 at 3:59 PM, Samuel Klein meta...@gmail.com wrote: Thanks Micru! I think we should start by including datasets on wikisource, with descriptions about them (storing the files on commons where possible). And adding more data formats to the formats accepted on commons. I don't follow you... why would you put datasets on Wikisource when they are only used in Wikipedia and have to be stored somewhere else? As it is now, it doesn't seem a good dataset management solution. Besides that it would conflict with its identity as repository for textual sources.. About Commons I don't know if it is relevant to their mission as a sharing media platform either... I hope someone from their community can share their views. Thanks for the input, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] A project to look forward to
http://www.slideshare.net/petermurrayrust/the-content-mine-presented-at-uksg ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
Property proposal started as: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#statement_disputed_by I guess all additional parameters (page, chapter, etc) can go in the references section. We will be able to say things like: birthfollowed bybaptism ---time span until next event 1-7 days ---disputed by GerardM What about the uncertainty qualifier? What would be a good name? statement considered uncertain by? Thanks, Micru On Tue, May 6, 2014 at 5:26 PM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Hoi, In the Netherlands it used to be that people were baptised as soon as possible after birth. The notion that he must have been born a few days earlier is not necessarily correct. Thanks, GerardM On 6 May 2014 17:18, Joe Filceolaire filceola...@gmail.com wrote: Having a property with multiple values can mean a number of things: * All the values are equally valid e.g. because a work has multiple authors * All values are valid but one is preferred - usually the current value e.g. when we have population figures back over time or all the kings of Denmark. * One of the values is shown because it is widely used but is deprecated because it is wrong e.g. Beethoven born on 17 December 1770 (that his date of baptism so he must have been born a few days earlier). The case described by Freidrich where we have two (or more values) which are both disputed (because they can't both be right) although one value is more widely supported then this is harder to represent semantically. I would go with adding a 'disputed by' qualifier to BOTH claims and marking the more widely accepted value as 'rank:preferred' But that is just me Joe ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
On Tue, May 6, 2014 at 1:37 PM, Thomas Douillard thomas.douill...@gmail.com wrote: We could create a new qualifier like ''contradicted by'' or ''disputed by''. The sourcs are a problem though as we can source only the totality of a claim, not only a qualifier of this claim, so we would have to source all the sources for the claim and it's disputation sources in the source without order.. I have mixed feelings about that... it is good because it doesn't require any development, it isn't that good because it mixes claim and source... And having a reference rank to indicate if the source is supporting, against or unsure about the claim seems too much work for the number of times that such feature would be needed Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] When the source says the information provided is dubious
Hi, I'm having some cases where a work has been attributed to an author by a source, but the source itself says this attribution is dubious, or it is contesting a previous attributions as spurious. As I see it, the rank of the statement is not deprecated (in fact it is normal or even preferred), but I have no way of representing this claim uncertainty or claim rebuttal. Is there any hidden parameter for this or should it be addressed with a qualifier? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
Hi Jane, No, I was not referring to books in particular, but of course it could be applied to books as well, and to works of art, and to many things in general. I agree that the statement is valuable and that it should be included, but I don't know how to represent it. Following your examples, what I am trying to represent is not what you say, but instead: a) uncertainty: it is hinted that Pete was the son of Klaus, but I have no conclusive proof b) rebuttal: Source A says that Pete was the younger brother of Klaus, I can disprove that (but I cannot provide an alternative) Cheers, Micru On Mon, May 5, 2014 at 2:10 PM, Jane Darnell jane...@gmail.com wrote: David, I assume you are referring to books. The same is true for works of art. The reason why these statements are still valuable is because it is an attribution based on grounds determined by someone somewhere and based on that loose statement alone are therefore considered of interest. You basically make a decision to include the statement or not, as you see fit. When it comes to people, one source may say Pete was the son of Klaus, while another source says Pete was the younger brother of Klaus. I think it's just a question of picking one on Wikidata to keep the family aspect of the relationship (whichever it is) intact, and sooner or later one or the other will be chosen. It's a wiki after all. Jane 2014-05-05 11:24 GMT+02:00, David Cuenca dacu...@gmail.com: Hi, I'm having some cases where a work has been attributed to an author by a source, but the source itself says this attribution is dubious, or it is contesting a previous attributions as spurious. As I see it, the rank of the statement is not deprecated (in fact it is normal or even preferred), but I have no way of representing this claim uncertainty or claim rebuttal. Is there any hidden parameter for this or should it be addressed with a qualifier? Cheers, Micru ___ 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] Bot request: 250+ thousands person data
On Tue, Apr 29, 2014 at 12:48 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: If you have something like between 1846 and 1855, you can use the before and after fields of the time value: time: +0001850-00-00T00:00:00Z, precision: 9, before: 4, after: 5 This means the main value is 1850, given as a year, with a lower bound four years before and an upper bound 5 years after the main value (before and after are given in the unit specified by the precision value). The main value is what is going to be displayed per default; it will also be used for sorting query results (once we have queries). Is it possible to have just an lower bond, leaving the upper one open? I am thinking of uses like https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#earliest_date For things like circa I don't see any clear solution other than inventing some ranges... Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Bot request: 250+ thousands person data
On Mon, Apr 28, 2014 at 3:10 PM, Luca Martinelli martinellil...@gmail.comwrote: I recalled the fact quite correctly: https://it.wikipedia.org/wiki/Modulo:Bio takes dates of birth and death from Wikidata. I think we can talk to extend the possibility to gender, and later to other fields. That's perfect, because that means that the bot can just delete the text on import. What is missing are the fields brth/death date after and before for uncertain dates (DataNascitaDopo/DataNascitaPrima?). I'm curious to see that working :) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Bot request: 250+ thousands person data
Maybe it is possible to identify those cases and not use wd data for them? They must represent a very tiny percentage of the total... Cheers, Micru On Sun, Apr 27, 2014 at 12:28 PM, Amir Ladsgroup ladsgr...@gmail.comwrote: there are some problems in using bio template for example they used it for a group of people https://it.wikipedia.org/wiki/Fratelli_Wright On Sun, Apr 27, 2014 at 2:51 PM, David Cuenca dacu...@gmail.com wrote: @Nemo, Apper: Do you think you could import that data into the wd-repo AND make use of it via an inclusion template? In the past there was some animosity against importing data without their sources, but if it is data that is being used and displayed on Wikipedia, then I guess it would be regarded differently. Anyhow, these kinds of discussions are better on-wiki. On Sun, Apr 27, 2014 at 11:16 AM, Christian Thiele ap...@apper.dewrote: The german dates have to be parsed, and I think the uncertainty for many persons is the main problem (born 5th of July 1716 or 15th of July 1718, between 1918 and 1921). But of course for a lot of persons there are accurate information, which could be imported to Wikidata. For this kinds of situation you have the before and after of the time datatype: https://www.wikidata.org/wiki/Special:ListDatatypes The problem is that it is not visible yet... https://bugzilla.wikimedia.org/show_bug.cgi?id=61909 Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Amir ___ 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] Wikibase/ Wikidata for structuring biodiversity knowledge
Hi Daniel, Interesting report, about WD tagging I would also mention Denny's qLabel: http://google-opensource.blogspot.de/2014/04/qlabel-multilingual-content-without.html Regarding cost-efficient tagging options, there are automated tagging/entity extraction methods like DBpedia Spotlight, which can be further improved by using them together with human supervision/custody around an established online community. I'm also unsure about the mark-up of semantically unaware publications, since marking-up requires access to an editable version of the text and that requires an open license. Semantic annotations don't seem to suffer of that problem and there are several open source initiatives in development. https://thepund.it/ http://www.openannotation.org/Partners.html Cheers, Micru On Wed, Apr 23, 2014 at 6:23 PM, Daniel Mietchen daniel.mietc...@googlemail.com wrote: Dear all, lately, I have been working on a report on mark-up and related approaches to structuring biodiversity information: https://docs.google.com/document/d/133szlTaabYakEeR6JF6FFYsDJH-bLdSgDby86XPxPDk/edit# Wikibase and Wikidata are featuring prominently in there, and I would appreciate your comments. Thanks and cheers, Daniel -- http://www.naturkundemuseum-berlin.de/en/institution/mitarbeiter/mietchen-daniel/ https://en.wikipedia.org/wiki/User:Daniel_Mietchen/Publications http://okfn.org http://wikimedia.org ___ 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] [OHM] Should we map former endonyms?
On Thu, Mar 20, 2014 at 9:45 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: A similar thing can be considered for streets and stuff as well. Obviously it needs a lot of thought but from an abstract point of view, a street or an image, it is just another category of data. When it works for one type of data it could / should work for another type of data as well. In that regard perhaps it would make more sense for OSM or another entity to run a Wikibase Repository dedicated exclusively to geographic entities/names. Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [OHM] Should we map former endonyms?
On Thu, Mar 20, 2014 at 1:31 PM, Jo winfi...@gmail.com wrote: I think wikidata has the potential to tie it all together. There is no need to split the information over 2 databases. It depends on how much granularity you want. If you want to use just well-known entities, then for sure, wikidata can tie it all together. If you want street level (or even building level) information, that would be too much for Wikidata. There was already a similar discussion regarding bibliographic data. Should Wikidata collect *all* bibliographic data? And the consensus was not all, just what is relevant as hinted by Wikipedia/Wikisource (and common sense). Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [OHM] Should we map former endonyms?
On Thu, Mar 20, 2014 at 3:36 PM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Given that we want to collaborate with openstreetmap we could host it for them I like the idea of a Wikibase-powered OSM data repository, it is a pity that the WM Incubator is only for language versions of existing projects and not for new projects... OTOH, since Wikidata is (or is supposed to be) language-agnostic, couldn't we argue that domain-specific data projects are to wikidata what language editions are to wikipedia? I wonder how hard would be to set-up a labs Wikibase instance for OSM developers to experiment with it? Or even if it would be enough interest? Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [OHM] Should we map former endonyms?
On Thu, Mar 20, 2014 at 5:17 PM, Susanna Ånäs susanna.a...@gmail.comwrote: An independent project will require a lot of MediaWiki related knowledge that is not necessarily found in an initial group of interested individuals. Or combined OSM, MediaWiki Wikidata knowledge, which may be even more sparse. It would be more relaxed in regard to rules and guidelines. Could it be re-integrated to Wikidata later, or would it run to in-evident oblivion? It could be re-integrated, but I wouldn't start a wikibase repo only for the specific case of historical data. If there is a sizeable community that could mantain a full-fledged repository of geographic entities (as understood in Wikidata terms), then the historic information could be a subset of that. OSM can do it (and actually it is being done more or less), but that is something that should be decided by their community. An integrated path would require complying to all guidelines eg. re: notability. It would cause a lot of waiting time for reaching consensus while defining properties - which is also needed in an independent project. I think the main intersection points are entities and properties. With entities it is already happening (using property p402https://www.wikidata.org/wiki/Property:P402), but with properties we still have no technical means of saying this property in WD is the same as this other property in project X. Are you going to be in the Zürich hackathon to discuss this? Not sure yet, but I have seen that Katie and Daniel will be there and they have a deeper technical knowledge than me :) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [OHM] Should we map former endonyms?
On Thu, Mar 20, 2014 at 6:28 PM, Jo winfi...@gmail.com wrote: Using property P402 is not a very good idea since object ids in OSM aren't guaranteed to be stable. nodes, ways and relations each have their own 'namespace' and sometimes information is refined by moving it from a node to a way or from a node or a way to a relation (multipolygon), usually this means he original object vanishes and property P402 isn't pointing anywhere anymore. The only way that makes sense is to add wikidata tags to OSM objects. Or that OSM would have their own repository of entities and then we would interlink both ;) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [OSM-talk] [OHM] Should we map former endonyms?
Well, that is one part of the problem, which could be addressed in Wikidata with a property official name with the datatype mono- or multi-lingual string (plannedhttps://www.wikidata.org/wiki/Wikidata:Development_plan#Multi-lingual_text_datatype_.28optional.29, but not available yet) plus the qualifiers start/end date. The other part of the problem is that for different periods of time you have different entities attached to geographic locations. For instance after the Kingdom of Great Britain https://www.wikidata.org/wiki/Q161885 Came the United Kingdom of Great Britain and Ireland https://www.wikidata.org/wiki/Q174193 Yes, the name changed, but it it not just a name change, it is a different entity. Cheers, Micru On Thu, Mar 20, 2014 at 6:43 PM, Andrew Gray andrew.g...@dunelm.org.ukwrote: I think the problem is that we sometimes need to reflect more than just the single official name - at the moment we include multilingual names, which is great, and it's a bit of a backwards step to lose that ability for the past. Imagine if you're looking at an English or German map of Russia - all the names rendered with nice Latin-script equivalents - and you say okay, show me a 1970s map, only for everything to become Cyrillic instead. :-) It becomes more complicated if you have cases where the name changes in some languages and not others, or countries with multiple official languages where it changes in both. For example, we'd want to be able to record that in English the city of Tsaritsyn became Stalingrad on a certain date, and then later became Volgograd, just as we record that in Russian it went from Царицын to Сталинград to Волгоград. However, as you can see at the moment, the other names are simple strings with no dates or modifiers, so we can't convey this information. (Switching the interface to a different language will display the alternative names in those languages) https://www.wikidata.org/wiki/Q914 Susanna: I'm not aware of what the plans are for this, but I'm reasonably sure we can't do it right now. However, I'm not completely up to speed on how dates/modifiers etc work, so someone on wikidata-l can no doubt correct me :-) Andrew. On 20 March 2014 13:24, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 20/mar/2014 um 13:51 schrieb Andrew Gray andrew.g...@dunelm.org.uk : Properties can have modifiers such as date, labels can't. So there's a bit of a challenge here - we would be able to construct a field that says historic name : Warschau (date:1939-45), but this would be shown as a historic name in Polish, German, English, Chinese... maybe that's not a problem as this was indeed the official name in that time? cheers, Martin -- - Andrew Gray andrew.g...@dunelm.org.uk ___ 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] [cultural-partners] Wikidata and GLAM
On Thu, Mar 20, 2014 at 12:53 AM, Andy Mabbett a...@pigsonthewing.org.ukwrote: P.S. I have just proposed an accession number property for Wikidata, which may also be of interest: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Unsorted#Accession_number I don't think it is necessary, we alredy have catalog code: https://www.wikidata.org/wiki/Property:P528 Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Interaction of VisualEditor with Wikidata
Hi, I have started writing some thoughts about a possible interaction between VE and WD. https://www.wikidata.org/wiki/User:Micru/Interaction_of_VisualEditor_with_Wikidata I assumed the following requirements: - link/unlink any template field to WD from VE - edit WD data from VE There are so many questions open... Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] New RFC: Organizing statements, sitelinks, and external identifiers
Hi, I have started a Request for Comments on how to organize statements, sitelinks, and external identifiers. Hopefully the feedback gathered can help with the UI redesign. https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Organizing_statements,_sitelinks,_and_external_identifiers Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Making Wikidata entries at the time of 'Article for Creation' publication
On Wed, Mar 12, 2014 at 2:52 PM, Andy Mabbett a...@pigsonthewing.org.ukwrote: I'm not sugegsting that we make people enter even more information in Wikipedia; I'm suggesting that wikidata would benefit from capturing the data that is /already/ being entered into Wikipedia, not least via AfC, by the people I describe above; and that I and others who review and publish those articles would benefit from tool to save us the manual task of having to retype (into Wikidata) what we're already asked to type once (into the AfC tool) as part of that process. We cannot get there yet, since we depend on many features still in development: 1.- Simple data editing from VisualEditor 2.- Easy way to map wikipedia template fields to wikidata properties 3.- Migration of main infobox templates to make use of Wikidata There are many needed features still not done, plus some more, which take a long time to discuss, implement, and test. Of course when all that is available then you should be able to have an infobox selection wizard (possibly based on this structure [1]), and then by editing the fields on VisualEditor the data would be automatically filled on Wikidata. As said, it sounds easy, but this has many prerequisites that are still not met. My only advice: patience :-) And if you want meanwhile you can help with the infobox mappings: https://www.wikidata.org/wiki/Wikidata:Infobox_mappings Cheers, Micru [1] https://en.wikipedia.org/wiki/Wikipedia:List_of_infoboxes ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Making Wikidata entries at the time of 'Article for Creation' publication
On Wed, Mar 12, 2014 at 6:11 PM, Andy Mabbett a...@pigsonthewing.org.ukwrote: What does this have to do with AfC? Indeed, nowhere in your post do you mention AfC, once. Because there is no difference between creating an article through enwiki-AfC or creating an article on any of the other 270+ language editions of WP. The general requirements are a simple interface and a streamlined workflow. If later you want to re-package it as AfC or anything else it is up to you, it doesn't affect the real problematic. On Wed, Mar 12, 2014 at 7:09 PM, Dimitris Kontokostas jimk...@gmail.comwrote: Actually there is a lot of work done in this regard. We map Wikipedia templates to the DBpedia ontology [1] and already started marking equivalent properties to Wikidata (see [2] [3]) Dimitris, I meant integrating the mapping info into the WP template data itself. Anyhow, thanks for the lead, maybe you could post it on the Wikidata:Infobox_mappings page too? It might simplify their work. Thanks, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Making Wikidata entries at the time of 'Article for Creation' publication
On Tue, Mar 11, 2014 at 12:36 PM, Joe Filceolaire filceola...@gmail.comwrote: I agree that it makes sense that one of the first things to do when creating a new wikipedia article should be to create an infobox which is automagically linked to the creation of a wikidata item. There are a number of considerations related to this. 1. Notability. The current rules for Wikidata means that it is not acceptable to create a wikidata item until after the Wikipedia article has been created. Most of the time superseded by clearly identifiable conceptual or material entity or structural need, but nevertheless important. 2. Drafts. English Wikipedia has recently enabled a Draft name space for people to use to develop new articles. Articles in the Draft namespace are not indexed by Google and are not required to meet notability standards until they are transferred to the Main namespace. Should we change the rules on wikidata so Draft articles can be sitelinked and have wikidata items? No idea how useful drafts are... or how often they move forward or get deleted. 3. Visual Editor. The visual editor already has some template editing functionality but it does not link to a wikidata item. To get Wikipedia editors editing wikidata we need an infobox creation wizard which will mean wikipedia editors can edit wikidata from inside wikipedia and it feels like they are editing an info box. Personally I think the first step should be to enable the wikibase client on wikidata so we can start developing these internationalised and localised infoboxes on wikidata which can then be redeployed to other WMF wikis. Totally agree. Even better would be to have a Infobox Reasonator, meaning a standard infobox that can be used for everything (perfect for small wikis). But for all that first we need Lua for testing the templates on WD: https://bugzilla.wikimedia.org/show_bug.cgi?id=47071 Which needs arbitrary access: https://bugzilla.wikimedia.org/show_bug.cgi?id=47930 And perhaps linking Wikidata pages as sitelinks, so Wikipedias can find our custom-made infoboxes easily https://bugzilla.wikimedia.org/show_bug.cgi?id=55570 As for WP-templates there is the need to be able to specify to which WD property should a template field default. No idea if that has been tracked/discussed somewhere. Coming back to the topic of new articles, I think it is important to note that most articles are categorized, and categories can give a hint about the properties common to all articles belonging to the category. It should be possible to semi-automate the process of creating wikidata items with an initial set of statements depending on the item category. Infoboxes also give hints about base statements. Thanks Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] rank related changes
Hi, I don't know which kind of wrong choices you are talking about, maybe you can expand on that? If you would have preferred labels to be treated as statements with ranks, qualifiers, etc, there are already properties like birth name (P513), short name (P743), etc. which are properties that you can use *now*, and nothing prevents you of proposing new properties in that direction for historical names. True that they would become more useful with the mono-/multi-lingual datatype, but it will be there some day. I cannot forget about what a structured Wiktionary will do in abstraction because that is a totally flawed argument. Same could have been said about Wikidata some time ago about the potential benefits to Wikipedia... The benefits are only known in abstraction, and only by doing it we'll know the answer. Even being technically more advanced, Omegwiki didn't gather a community for a number of reasons. Wiktionary managed to gather a community, but has strong technical flaws. Don't you think it is worth it to learn the lessons from each site and forget about one-sided preferences? Thanks, Micru On Mon, Mar 10, 2014 at 2:27 PM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Hoi, When you look at the current use of labels, they are used to identify items. When a statement is used on an item, it uses a combination of a property and another item. What we notice is that several not so smart choices have been made in the past that make the current use of labels problematic. I remind you of the discussion of calling an item a list when it is used an a single instance. The notion that labels on statements are not used flies in the face of it being applied in Reasonator for instance. Forget about what a structured Wiktionary will do in abstraction, it is not where we are. We are at a point where we have labels and no clue (in a Wikidata context) if and what practical benefits embedding Wiktionary will bring. It is really nice to point to Lemon and say that it is a standard. But as far as I am concerned it is a lemon [1] when there is no translation in how the information can be leveraged. I can appreciate that we have simple labels at this time. It will not stay that way. The alternative is that including Wiktionary in Wikidata will truly become a lemon [1]. I will do what I can to help prevent that, my ambition is that Wikidata will truly replace Omegawiki. Thanks, GerardM [1] A defective https://en.wiktionary.org/wiki/defective or inadequatehttps://en.wiktionary.org/wiki/inadequateitem. On 10 March 2014 14:03, David Cuenca dacu...@gmail.com wrote: On Mon, Mar 10, 2014 at 1:50 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used. The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search. Lexemes UI/search is not clear, but it can be clarified when needed. I don't think now it is the time, maybe after getting some experience with queries. The current labels will one on one coincide with lexemes. I think we can agree on this. Not always, not for all the languages, and not necessarily. A structured Wiktionary should be the interface to written (and hopefully spoken) human language. Q-item labels are for humans to have some clue what the concept is about, but the textual expression is a different topic. Thanks, Micru ___ 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Queries - can they be stored as statements in Category/List items?
On Fri, Mar 7, 2014 at 6:37 PM, Denny Vrandečić vrande...@gmail.com wrote: I still disagree - let me explain why. I think that trying to express a query definition into a single statement is very hard. Having a specific Query namespace allows us to create a completely new UI for them, allows us to use a different data model for Queries than for items, and allows us to treat Query pages very different (e.g. for caching) than, e.g. item pages. Maybe I'm wrong, but to create a completely new UI for [queries] in my head translates as more barriers for users to understand and navigate Wikidata. The query doesn't need to be a single statement, but a single property for queries (I called it same as query but it could be named differently). You should be able to combine two statements of such property, or more, to create a complex query. What I think it also matters is to reuse the concepts the users are familiar with as much as possible. For example, the different data model would allow us to restrict the number of queries on a page. If they were just a statement, what would stop a contributor from creating several such statements on one page? On the mockup I intended to represent that the property same as query can have several statements, but they combine into a single query. What happens when someone removes the same as query statement? Same as now happens with other statements transcluded into wikipedia pages, when somebody notices the deletion, it gets restored. What happens if someone adds it to the page for USA (e.g. same as query instance of-country, continent-North America, population-300M)? It will get corrected, it is a wiki, right? :) Would this page suddenly be treated differently? Not necessarily. Also, you already show in your mock up that the same as query statement requires plenty of special code (e.g. for the different visualizations, etc.) Same requirements as having queries as independent pages. One option would be to have them as item pages, but then treat them continuously different. This would mean more and more exceptions and special casing in the code. I think that Queries and Items are sufficiently different to deserve their own treatment. In my personal opinion, this is provides sufficient reasons for Query pages and Item pages being distinct. No need for different treatment, or exceptions. Just a property that acts as a query descriptor with as many modifiers as needed. What would be the advantage of having Queries being expressed in the Items? Less entities? Yes! Less confusion about what these list of- and category-items mean? Yes! Both reasons I don't find sufficiently enticing to change my opinion on this. And better navigation, and more simplicity to create a query, and no need of creating artificial divisions between pages that represent the same concept... Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Queries - can they be stored as statements in Category/List items?
Denny, sorry for the confusion, it is a complex topic, or it could also be that I am terribly bad at explaining :) Based on that item page I have made a mock-up which perhaps makes things easier: http://i.imgur.com/1dSfrqx.png The reasoning for this being: 1) there is a well-defined set of queries that are equivalent to categories/lists, so there is no need to have independent query pages 2) if a wikipedia wants to include query results on a page, it is quite probable that the query already exists as a list/category 3) and if it doesn't then it will be *very* specific to that language wikipedia. In that case there is no need to define a query page on wikidata, but on the wikipedia page itself as an inclusion syntax command or another similar module You are right that it might be a bit preliminary, as there are not even simple queries yet, but since this kind of decisions might have an impact on later design, I think it is worth start presenting the concepts/options now. Besides, ideas and a common understanding take time to develop, and the RFC was started, so I thought it was worth giving it some attention. Cheers, Micru On Fri, Mar 7, 2014 at 12:18 AM, Denny Vrandečić vrande...@gmail.comwrote: Since I am obviously bad at guessing what you mean, can you please explicate what you mean with replicate that functionality on Wikidata? Sorry, I am too dense to understand it. What do you want to happen, explicitly? I go to http://www.wikidata.org/wiki/Q6573995 - how should it be different from what it displays today? Do you want the item pages to have the feature to directly embed query results, instead of having a one-click distance to the actual query page and its results? Or is there more to it? On Thu Mar 06 2014 at 3:10:44 PM, David Cuenca dacu...@gmail.com wrote: I'm not saying that the results yielded by Category:Books by Jean-Paul Sartre or Category:Books by J.R.R. Tolkien are or should be the same as the result yielded by a corresponding Wikidata query, but the concepts they represent, they are the same. Ditto for lists. (As a further clarification, I didn't mention anything about changing Wikipedia categories or Wikipedia lists either.) My question was regarding the functionality of WD items associated with Wikipedia categories and Wikipedia lists. Conceptually those items represent (or can represent) queries. WDQ, the tool by Magnus, already can interpret certain statements as queries [1]. Would it make sense to replicate that functionality on Wikidata? Cheers, Micru [1] http://tools.wmflabs.org/reasonator/?q=6573995 On Thu, Mar 6, 2014 at 11:16 PM, Denny Vrandečić vrande...@gmail.comwrote: But that's simply not the case. The Category:Books by Jean-Paul Sartre [1] or Category:Books by J.R.R. Tolkien [2} neither are a complete list of books by those authors (e.g. Sartre's fictional books are missing, Tolkien's non-fictional *and* Middle earth books are missing), nor are they only including books by Tolkien (e.g. they also include templates and other categories, which are likely not written by Sartre or Tolkien). If the plan is to change the way categories are used in Wikipedia and the other Wikimedia wikis, I'd say this is a very different goal, but should be discussed on those wikis. List-articles often contain much more love and care than a Wikidata query result will for a while. I don't think that replacing an article like the list of books by David Foster Wallace [3] the List of US Presidents [4] with a single simple query is a short-term goal. [1] https://en.wikipedia.org/wiki/Category:Books_by_Jean-Paul_Sartre [2] https://en.wikipedia.org/wiki/Category:Books_by_J._R._R._Tolkien [3] https://en.wikipedia.org/wiki/Books_by_David_Foster_Wallace [4] https://en.wikipedia.org/wiki/List_of_US_Presidents On Thu Mar 06 2014 at 1:49:54 PM, David Cuenca dacu...@gmail.com wrote: The point I wanted to make (following your example), is that the Wikidata Query All novels by Douglas Adams is equivalent to the item Category:Novels by Douglas Adams [1]. In other cases there will be even 3 items representing the same information: the wd query, the category item, and a list of... item. So I'm just wondering if this complexity is really needed for structural/technical reasons. Maybe there is an easier way instead of linking to the wd query with a category's main query property? Cheers, Micru [1] https://www.wikidata.org/wiki/Q8687492 On Thu, Mar 6, 2014 at 7:24 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Tue, Mar 4, 2014 at 9:01 PM, David Cuenca dacu...@gmail.com wrote: I would like to make you aware of this RFC started by Gerard: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Define_lists_on_both_%22Wikimedia_lists%22_and_%22Wikimedia_categories%22 It is interesting because in the end, what is the difference between a list, a category, and a query? Not much, really. I'm curious
Re: [Wikidata-l] Queries - can they be stored as statements in Category/List items?
I'm not saying that the results yielded by Category:Books by Jean-Paul Sartre or Category:Books by J.R.R. Tolkien are or should be the same as the result yielded by a corresponding Wikidata query, but the concepts they represent, they are the same. Ditto for lists. (As a further clarification, I didn't mention anything about changing Wikipedia categories or Wikipedia lists either.) My question was regarding the functionality of WD items associated with Wikipedia categories and Wikipedia lists. Conceptually those items represent (or can represent) queries. WDQ, the tool by Magnus, already can interpret certain statements as queries [1]. Would it make sense to replicate that functionality on Wikidata? Cheers, Micru [1] http://tools.wmflabs.org/reasonator/?q=6573995 On Thu, Mar 6, 2014 at 11:16 PM, Denny Vrandečić vrande...@gmail.comwrote: But that's simply not the case. The Category:Books by Jean-Paul Sartre [1] or Category:Books by J.R.R. Tolkien [2} neither are a complete list of books by those authors (e.g. Sartre's fictional books are missing, Tolkien's non-fictional *and* Middle earth books are missing), nor are they only including books by Tolkien (e.g. they also include templates and other categories, which are likely not written by Sartre or Tolkien). If the plan is to change the way categories are used in Wikipedia and the other Wikimedia wikis, I'd say this is a very different goal, but should be discussed on those wikis. List-articles often contain much more love and care than a Wikidata query result will for a while. I don't think that replacing an article like the list of books by David Foster Wallace [3] the List of US Presidents [4] with a single simple query is a short-term goal. [1] https://en.wikipedia.org/wiki/Category:Books_by_Jean-Paul_Sartre [2] https://en.wikipedia.org/wiki/Category:Books_by_J._R._R._Tolkien [3] https://en.wikipedia.org/wiki/Books_by_David_Foster_Wallace [4] https://en.wikipedia.org/wiki/List_of_US_Presidents On Thu Mar 06 2014 at 1:49:54 PM, David Cuenca dacu...@gmail.com wrote: The point I wanted to make (following your example), is that the Wikidata Query All novels by Douglas Adams is equivalent to the item Category:Novels by Douglas Adams [1]. In other cases there will be even 3 items representing the same information: the wd query, the category item, and a list of... item. So I'm just wondering if this complexity is really needed for structural/technical reasons. Maybe there is an easier way instead of linking to the wd query with a category's main query property? Cheers, Micru [1] https://www.wikidata.org/wiki/Q8687492 On Thu, Mar 6, 2014 at 7:24 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Tue, Mar 4, 2014 at 9:01 PM, David Cuenca dacu...@gmail.com wrote: I would like to make you aware of this RFC started by Gerard: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Define_lists_on_both_%22Wikimedia_lists%22_and_%22Wikimedia_categories%22 It is interesting because in the end, what is the difference between a list, a category, and a query? Not much, really. I'm curious to know if the approach taken with queries will be the same as the WDQ http://tools.wmflabs.org/reasonator/?q=6573995 Items like List of... or Category: would have some use, but the development notes don't state if this is the intended path https://meta.wikimedia.org/wiki/Wikidata/Development/Queries Any thoughts about it? I've been trying to understand the RfC 3 times now and still fail. So I can't answer your questions unfortunately. The short and simplified version of how complex queries will work: * someone defines a query on a page in a special query namespace (eg everything that has author = Douglas Adams) * the result of the query is a list of items matching the query * the Wikipedias can include the result of the query and visualize it in certain ways on a page. (eg the wikitext of the article List of works by Douglas Adams would have a call to include the query result from Wikidata) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- 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] Question about progressive loading
While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive loading of items was not an option for Wikidata. Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons? Thanks! Micru [1] docforge.com/wiki/Web_application/Progressive_loading ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Question about progressive loading
Just noticed about it! Yesterday I took me almost 5min and many unresposive script errors to load Russia, now it is under a minute of computer freeze :) https://www.wikidata.org/wiki/Q159 Not optimal but definitely a big leap forward. Great work! Still curious about progressive loading (at least for big items). Cheers, Micru On Tue, Feb 25, 2014 at 8:58 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Tue, Feb 25, 2014 at 8:55 PM, David Cuenca dacu...@gmail.com wrote: While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive loading of items was not an option for Wikidata. Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons? We've just made a huge improvement like 2 minutes ago ;-) More will follow. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata-Freebase mappings published under CC0
Hi Denny, I asked again about this property because there were some concerns when it was created. From the comments I infer that the general ethos is not against, but not thrilled either: https://www.wikidata.org/wiki/Wikidata:Project_chat#Freebase-Wikidata_mappings I share the feeling, I don't mind linking, but I see little utility for Wikidata given the different licenses. Cheers, Micru On Mon, Nov 11, 2013 at 11:34 PM, Denny Vrandečić vrande...@google.comwrote: Hi Max, indeed, I am not suggesting creating a new property. The data release that was made today basically provides data for P646. Cheers, Denny Regarding the off-topic part of your mail, I want to point out to my personal opinion with regards to data licensing, which was formulated before I started my current job: http://simia.net/wiki/Free_data . This is solely my opinion though, but it did influence my voice in the decision-making process around the license for Wikidata in my previous job. On Mon, Nov 11, 2013 at 12:22 PM, Klein,Max kle...@oclc.org wrote: Hello All, We already do have a freebase ID, similar to the VIAF one- it's P646http://www.wikidata.org/wiki/Property:P646 . I just went back into the email Archives and a discussion started on 6/14/2013 by Google Developer Relations person Shawn Simister[1] first proposed this property. There is large thread there about licensing, ending with Micru having an unanswered question to Shawn about how Freebase can manage its license since it mixes CC-0 and CC-BY? Off-topic: this thread is from before Denny announced that he was going to Google, I believe, is that correct? Whatever happens with licensing, and regarding Wikidata's CC0, I hope that it wasn't engineered so that Google could profit from Wikidata. I concede that this thought is mostly from paranoia, and disagreeing with a lot of Google's politics and tactics in the past. [1] https://plus.google.com/+ShawnSimister Maximilian Klein Wikipedian in Residence, OCLC +17074787023 -- *From:* wikidata-l-boun...@lists.wikimedia.org wikidata-l-boun...@lists.wikimedia.org on behalf of Gerard Meijssen gerard.meijs...@gmail.com *Sent:* Monday, November 11, 2013 11:27 AM *To:* WikiData-l *Subject:* Re: [Wikidata-l] Wikidata-Freebase mappings published under CC0 Hoi, If I understand you well, what you propose is adding links that are similar to what we already do to VIAF and so many others. Using data from Freebase is a tantalising option. Is there agreement and a license that allows for this? Thanks, GerardM Op 11 nov. 2013 19:35 schreef Denny Vrandečić vrande...@google.com: Hello all, as you know, I have recently started a new job. My mission to get more free data out to the world has not changed due to that, though. Thus, I am happy to point you today to a step in this direction. We have created a mapping of Wikidata Qids to Freebase Mids, and are publishing it under CC0, so that anyone can use it in any way they want. The file contains about 2 Million mappings. The download and all further data is available here: https://developers.google.com/freebase/data#freebase-wikidata-mappings In particular, I hope that the data will be uploaded to Wikidata. We also plan to upload the data to Freebase. The two-way links will ensure that systems using either knowledge base can easily merge data, go from one to the other, enrich data with each other, etc. We opted to first publish the mappings standalone, to make clear that they are under CC0. The mapping is created based on the Wikidata dumps from end of October. Wikidata Items are matched with Freebase Topics based on their respective links to Wikipedia. Each mapping says that there have been no disagreeing Wikipedia-Links and at least two agreeing Wikipedia-Links, so the data should be very clean. Furthermore, the mappings are sorted by the number of agreeing Wikipedia-Links, so it is kinda sorted by relevance. The data is in RDF format. To get the Mids as they are used in Wikidata, the replace the namespace http://rdf.freebase.com/ns/m. with /m/ The Wikidata Qids are using the Wikidata namespace, i.e. the Qids themselves are concatenated to http://www.wikidata.org/entity/ If anyone wants to take up the task to upload the data to Wikidata, I can offer to help and answer questions and to help. Cheers, Denny ___ 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 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non
Re: [Wikidata-l] next sister project: Wikisource
The sitelinks are not used directly, they are aggregated by using the work item as a central hub. Basically the algorithm is: 1.- query all edition-items that are connected to the same work-item using edition of 2.- make a list of all the sitelinks used on each one of these edition-items (1 sitelink per edition-item) 3.- for each wikisource page connected to an edition-item, display the list generated on point 2 Micru On Fri, Nov 8, 2013 at 6:49 PM, Joe Filceolaire filceola...@gmail.comwrote: Actually the problem isn't that you can only have one link from a wikisource work from a wikidata item. We have separate wikidata items for each edition of a work (because these have different metadata) so multiple editions of the same work on a wikisource link to different wikidata items. This creates a different problem. Each language edition of a work is a different edition so it links to a different wikidata item which has sitelinks only to that translation of the work. This means you can't use sitelinks to link to translations of a work on other wikisources. Does this mean wikidata sitelinks are useless for wikisource? filceolaire ___ 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] next sister project: Wikisource
On Tue, Nov 5, 2013 at 5:35 PM, Daniel Kinzler daniel.kinz...@wikimedia.dewrote: However, MediaWiki only supports one link per target site in the sidebar. Maybe an on-page navigation box could be used instead of proper language links? With the help of JavaScript, the contents of that nav box could then be moved into the sidebar. That's a bit hackish, but would work ok, I think. On English Wikisource they were using this template to allow more than one link per language: https://en.wikisource.org/wiki/Template:Interwiki-info However it seems that is not working now on this page (the interwiki list should be much larger according to the wikitext): https://en.wikisource.org/wiki/The_Raven_%28Poe%29 I think it would be a good idea to always have that, for consistency and structural integrity. It makes sense to create work pages for works with several editions in a given language (5-10% depending on language) since it is the equivalent of having a desambiguation page, but having a big number of work pages on Wikisource for works that only have one edition might be detrimental for the user experience, unless they are redirects. How far is the development of using redirect pages as sitelinks? --Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] next sister project: Wikisource
On Wed, Nov 6, 2013 at 4:22 PM, Daniel Kinzler daniel.kinz...@wikimedia.dewrote: MediaWiki used to handle this inconsistently: multiple links for the same language where shown in the sidebar, but not recorded in the database. This inconsistency was fixed a few months ago - now, only one link per page can exist. I suppose that's why the template no longer works. Someone's bug is someone else's feature... Anyhow, on fr-ws they already have a custom menu on the left to link with other wikimedia projects (Compléments) which is loaded by: https://fr.wikisource.org/wiki/MediaWiki:Common.js Example: https://fr.wikisource.org/wiki/Victor_Hugo If you want to add a similar menu for editions then it should be compatible with: https://www.mediawiki.org/wiki/Extension:DoubleWiki I'm not suggesting to always great a work *page* on wikisource, even if there is only one edition in that language. I'm saying that there should always be an *item* for the work on wikidata, even if there is only an item for one edition. Sorry, I misunderstood you. Yes, I agree it makes sense to create an item for the work on wikidata. Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] next sister project: Wikisource
On Mon, Nov 4, 2013 at 4:43 PM, Daniel Kinzler daniel.kinz...@wikimedia.dewrote: Am 04.11.2013 16:10, schrieb Amir Ladsgroup: If you're using statement instead of site link who we can trace item from article of wikisource to wikidata This will very soon be possible with queries. Actually a query or Lua would be much better solution for Wikisource instead of sitelinks (well, author pages can have sitelinks that is no problem). According to the data model that we have been defining for Wikisource [1] there should be a top-level item (work item) representing all the editions that a text has, then there should be sub-items for each edition (example of a book with several translations [2]). Each one of those sub-items is the one that should be connected with a sitelink, although there will be only of them per item. Ideally, the script or the query should examine which items are connected with the property pair edition/edition of, collect the sitelink of each language and list them all for each one of them. Is that factible? Cheers, Micru [1] https://www.wikidata.org/wiki/Wikidata:Books_task_force [2] https://www.wikidata.org/wiki/Q6911 ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] next sister project: Wikisource
Excellent news! :) For the author pages it is quite straight-forward. For the bibliographic metadata the easiest would be to connect wikidata items with the Book: page generated by the (planned) Book Manager extension. The Book: page is supposed to provide the book structure and act as a metadata hub for both books with scans (those with Index: page) and books without scans (there was no solution for those yet) Project page: https://meta.wikimedia.org/wiki/Book_management Bugzilla page: https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 Example: http://tools.wmflabs.org/bookmanagerv2/mediawiki/index.php?title=Book:The_Interpretation_of_Dreamsaction=edit Problem, the extension is not finished yet and neither Molly nor Raylton have time to keep working on it. Some bugs are still open and the fields in the template would need to be maped to Wikidata properties. All this is not relevant for phase 1 (if it is done only for books), but it will become relevant for phase 2. Is there anyone that could volunteer as an OPW mentor to help a potential student to finish this project? Cheers, Micru On Sat, Nov 2, 2013 at 4:30 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey everyone, The next sister project to get language links via Wikidata is Wikisource. We're currently planning this for January 13. The coordination is happening at https://www.wikidata.org/wiki/Wikidata:Wikisource On this page we're also looking for ambassadors to help spread the messages to the different language editions of Wikisource. Please help if you can. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Proposed change to the inclusion synthax
Hi,
I would like to know your opinion about having the value in the #property
parser function. Right now we have two options:
{{#property:P36}}
{{#property:capital}}
The problem with this model is that editors in wikipedia cannot see the
value unless they render the page (or possibly use the VisualEditor).
Having the value in the property parser itself would allow contributors to
see and edit the value in Wikipedia, which would in turn update the
Wikidata value. Of course updating the value in Wikidata will also update
the text field. It could look like
{{#property:P36|value=Berlin}}
{{#property:capital|value=Berlin}}
Or maybe:
{{#property:P36=Berlin}}
{{#property:capital=Berlin}}
What is your opinion about it?
Cheers,
Micru
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Proposed change to the inclusion synthax
@Sven: AFAIK, whenever there is a change in the data, the change is shown
as an edit, that way editors can keep an eye on the changes, even if there
is a continuous stream of edits. In that regard there would stay as it is
now.
@Vito: what do you mean by data's scope?
Micru
On Sun, Oct 20, 2013 at 12:17 PM, Sven Manguard svenmangu...@gmail.comwrote:
Excuse me in advance, as this isn't an area I am well versed in, but:
{{#property:P36}} doesn't have to change if the value changes, but an edit
would have to be made to modify {{#property:P36|value=Berlin}} if the
value changed. Now capitals don't change, but if we have a value for Alexa
rank or annual GDP or population, well those change often. Part of the
utility of Wikidata is that on smaller projects once you set everything up
you don't need a continuous stream of edits.
Sven
On Oct 20, 2013 3:06 PM, Vito vituzzu.w...@gmail.com wrote:
Il 20/10/2013 20:30, David Cuenca ha scritto:
Hi,
I would like to know your opinion about having the value in the
#property parser function. Right now we have two options:
{{#property:P36}}
{{#property:capital}}
The problem with this model is that editors in wikipedia cannot see the
value unless they render the page (or possibly use the VisualEditor).
Having the value in the property parser itself would allow contributors to
see and edit the value in Wikipedia, which would in turn update the
Wikidata value. Of course updating the value in Wikidata will also update
the text field. It could look like
{{#property:P36|value=Berlin}}
{{#property:capital|value=**Berlin}}
Or maybe:
{{#property:P36=Berlin}}
{{#property:capital=Berlin}}
What is your opinion about it?
Cheers,
Micru
Then what will be data's scope? :/
Vito
__**_
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
___
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] Open tabular data
Hi Dario, Thanks for sharing this proposal. As posted in the talk page, I believe that it would be a great opportunity to partner with dedicated organizations like Datahub [1] (OKFN/CKAN). Wikidata could also play an important role in semantically describing how to interpret the information, for instance mapping the fields of raw data to wikidata properties or describing semantically the contents of the file. The DataNamespace could be used to render selected portions of a large file, which would be too much to handle in real time. Cheers, Micru [1] http://datahub.io/ On Tue, Aug 27, 2013 at 8:06 PM, Dario Taraborelli dtarabore...@wikimedia.org wrote: I'd like to hear from the people on this list on a proposal to create a dedicated namespace to host open (tabular) data and make these datasets persistently identifiable, version controlled and easily embeddable into other wikis. While this use case is currently not within the scope of Wikidata (and could potentially live on other Wikimedia wikis, like Meta or Commons), I'd appreciate input from the wikidata community on this draft: https://meta.wikimedia.org/wiki/DataNamespace Some interesting discussion on the talk page: http://meta.wikimedia.org/wiki/Talk:DataNamespace Dario ___ 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] 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
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] URL datatype needs testing
I cannot see it on the new property data type list: http://test.wikidata.org/wiki/Special:NewProperty Only item, geocoord, time, string, file... On Fri, Aug 23, 2013 at 1:21 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Fri, Aug 23, 2013 at 7:19 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: When testing please be aware that URLs are right now not checked against the spam blacklist and that there is an issue with too long URLs. Pressed sent too early... Those obviously are on our list of things to fix before deployment. 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 -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikimedia-l] Meeting about the support of Wiktionary in Wikidata
To add up a couple of comments to what Denny said, from my experience with Wikisource, reaching out to international, loosely connected communities is already a big challenge on its own. I would like to invite Wiktionary contributors to take a look to this Individual Engagement Grant project that Aubrey and me are doing for Wikisource, because maybe it would make sense that a group of involved Wiktionarians started a similar initiative for Wiktionary. The original application can be found here: http://meta.wikimedia.org/wiki/Grants:IEG/Elaborate_Wikisource_strategic_vision And the midterm report: http://meta.wikimedia.org/wiki/Grants:IEG/Elaborate_Wikisource_strategic_vision If anyone from the Wiktionary community wants to step forward, I would be more than happy to share experiences and provide advice. Cheers, Micru On Sat, Aug 10, 2013 at 3:30 AM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: [Sorry for cross-posting] Yes, I agree that the OmegaWiki community should be involved in the discussions, and I pointed GerardM to our proposals whenever and discussions, using him as a liaison. We also looked and keep looking at the OmegaWiki data model to see what we are missing. Our latest proposal is different from OmegaWiki in two major points: * our primary goal is to provide support for structured data in the Wiktionaries. We do not plan to be the main resource ourselves, where readers come to in order to look up something, we merely provide structured data that a Wiktionary may or may not use. This parallels the role of Wikidata has with regards to Wikipedia. This also highlights the difference between Wikidata and OmegaWiki, since OmegaWiki's goal is to create a dictionary of all words of all languages, including lexical, terminological and ontological information. * a smaller difference is the data model. Wikidata's latest proposal to support Wiktionary is centered around lexemes, and we do not assume that there is such a things as a language-independent defined meaning. But no matter what model we end up with, it is important to ensure that the bulk of the data could freely flow between the projects, and even though we might disagree on this issue in the modeling, it is ensured that the exchange of data is widely possible. We tried to keep notes on the discussion we had today: http://epl.wikimedia.org/p/WiktionaryAndWikidata My major take home message for me is that: * the proposal needs more visual elements, especially a mock-up or sketch of how it would look like and how it could be used on the Wiktionaries * there is no generally accepted place for a discussion that involves all Wiktionary projects. Still, my initial decision to have the discussion on the Wikidata wiki was not a good one, and it should and will be moved to Meta. Having said that, the current proposal for the data model of how to support Wiktionary with Wikidata seems to have garnered a lot of support so far. So this is what I will continue building upon. Further comments are extremely welcomed. You can find it here: http://www.wikidata.org/wiki/Wikidata:Wiktionary As said, it will be moved to Meta, as soon as the requested mockups and extensions are done. Cheers, Denny 2013/8/10 Samuel Klein meta...@gmail.com Hello, On Fri, Aug 9, 2013 at 6:13 PM, JP Béland lebo.bel...@gmail.com wrote: I agree. We also need to include the Omegawiki community. Agreed. On Fri, Aug 9, 2013 at 12:22 PM, Laura Hale la...@fanhistory.com wrote: Why? The question of moving them into the WMF fold was pretty much no, because the project has an overlapping purpose with Wiktionary, This is not actually the case. There was overwhelming community support for adopting Omegawiki - at least simply providing hosting. It stalled because the code needed a security and style review, and Kip (the lead developer) was going to put some time into that. The OW editors and dev were very interested in finding a way forward that involved Wikidata and led to a combined project with a single repository of terms, meanings, definitions and translations. Recap: The page describing the OmegaWiki project satisfies all of the criteria for requesting WMF adoption. * It is well-defined on Meta http://meta.wikimedia.org/wiki/Omegawiki * It describes an interesting idea clearly aligned with expanding the scope of free knowledge * It is not a 'competing' project to Wiktionaries; it is an idea that grew out of the Wiktionary community, has been developed for years alongside it, and shares many active contributors and linguiaphiles. * It started an RfC which garnered 85% support for adoption. http://meta.wikimedia.org/wiki/Requests_for_comment/Adopt_OmegaWiki Even if the current OW code is not used at all for a future Wiktionary update -- and this idea was proposed and taken seriously by the OW devs -- their community of contributors should be part of
[Wikidata-l] Meeting about the support of Wiktionary in Wikidata
wiktionar...@lists.wikimedia.orgHi, If there is someone in Wikimania interested in participating in the talks about the future support of Wiktionary in Wikidata, we will having a discussion about the several proposals. http://wikimania2013.wikimedia.org/wiki/Support_of_Wiktionary_in_Wikidata Date : Saturday, 10 Aug, 11:30 am - 1:00 pm Place: Y520 (block Y, 5th floor) See you there, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
