Wikidata

wikidata@lists.wikimedia.org

15 participants
4196 discussions

[Wikidata-l] Wikipedia Categories vs. UDC
by Ivan Herman 07 Apr '12

07 Apr '12

I ran into this visualization today: http://scimaps.org/maps/map/design_vs_emergence__127/ To be honest, I am not sure I fully understand what I see in detail on the chart, though. Maybe somebody who knows better UDC and the WP categories may make more sense of it (you can click on the image and then you can zoom in) Ivan ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf

1 0

[Wikidata-l] relevant work on infobox alignment
by Brent Hecht 06 Apr '12

06 Apr '12

Hi All, I just wanted to make sure folks had seen this paper by Eytan Adar, Michael Skinner, and Daniel Weld (big names in AI). It's precisely about aligning infoboxes and propagating information across multiple language editions, so it might help guide the process when we get to that stage (and even earlier): http://www.cond.org/paper_202.pdf - Brent Brent Hecht Ph.D. Candidate in Computer Science CollabLab: The Collaborative Technology Laboratory Northwestern University w: http://www.brenthecht.com e: brent(a)u.northwestern.edu

1 0

Re: [Wikidata-l] SNAK -> assertion?
by JFC Morfin 06 Apr '12

06 Apr '12

Binàris, then you should coin a crystal clear definition of snak (could it be made an acronym?) everyone can memorize and understand. Sounds also as snap and snag. If you find a pun it would help it get accepted. jfc At 10:39 06/04/2012, Bináris wrote: >2012/4/5 Gregor Hagedorn ><<mailto:g.m.hagedorn@gmail.com>g.m.hagedorn(a)gmail.com> > >I still feel uneasy about the hard-to-remember-neonym. > >It was strange to me and had to read after it. You may remember as >bit-->byte-->snack, growing pieces of food. > > >I cannot prove >it, but believe the term snak will have to be learned by anyone who >interacts with the system through the API, any form of import >mechanism, etc. > >Well, and what's then? They will learn. Once I thought namespaces to >be a rather programming word and concept, but then I became a >Wikipedian and understood they were a basic concept of editing. >Every Wikipedian must know the difference between article and user >and project namespace and they are not afraid of the word even if >they have no real knowledge about namespaces in programming. People >must understand concepts and ideas, and for the majority of >non-English, non-programmer people it will be quite the same >whatever name the new concept has. More, a sna(c)k fits better to >every day concepts of an avarage person than an assertion, doesn't it? > > >-- >Bináris >_______________________________________________ >Wikidata-l mailing list >Wikidata-l(a)lists.wikimedia.org >https://lists.wikimedia.org/mailman/listinfo/wikidata-l

1 0

Re: [Wikidata-l] Industry, JTC1/ISO, W3C, IUse, Wikimedia - where are we ?
by JFC Morfin 06 Apr '12

06 Apr '12

At 12:45 05/04/2012, Denny VrandeÄiÄ wrote: >In short, we have for Wikidata two pragmatic goals: >* Wikidata's first aim is to support the Wikipedias with their language links >* Wikidata's second aim is to support the Wikipedias with the infoboxes > >Out of the support for these tasks, other interesting use cases >might and are expected to arise. > >Until I manage to understand how your comments relate to one of >these goals, I will personally take the liberty to ignore your comments. Fair enough :-) Your assesments are correct. As I first documented it, our (iucg(a)ietf.org) target in this area is the Internet+ (smart fringe to fringe Internet) MDRS (metadata registry multilinguistic distributed referential system). The MDRS is to the Internet+ and to the Semiotic Internet (Intersem) that we explore, what the IANA is to the legacy Internet, and what Wikidata might be to Wikimedia. Our "use case" is the Internet+ distributed operations (I documented the IETF Drafts references). The MDRS will most probably be a datawiki or/and a DDDS (the DNS is a DDDS) of some sort. Todays IANA and wikis are humanly fed and read, datawikis will be more and more fed and read by intelligent processes. This intelligence leads to additional opportunities and constraints. Our targets are the same, however you have to have conceptual limits, while by essence I must have none. This is why I tried to poke our possible common interest areas. Your two confirmed documents now gives us your current limits (the more people understand what the "revolution" (as per wikimedia) datawikis are going to be, the more they may expect from them). My own target is to internally review these documents, assess their possible evolution, strive to stay interoperable, and permit users and applications to take a better advantage from your project (wikidata.iucg.org). We will alert you if we fear possible architectural conflicts through our work and tests. This seems to be in line with what Lydia responded today. Best jfc

1 0

Re: [Wikidata-l] Namespace-based model
by John McClure 06 Apr '12

06 Apr '12

It's more accurate to say that your belief is an artifact of present tools. RDF has just one way to associate a Class with an object, the rdf:type attribute. Specifically because RDF makes no distinction between classes that represent a type-of-thing (eg a Character) and classes that represent a facet-of-thing (eg Fictional), present tools require multiple classes to be able to be associated with any resource. Obviously a given resource can have multiple facets. In my work I store facet-classes in the Dublin Core Coverage and Format properties and I store a single existential-class in the Dublin Core Type property for the page; the page's template restates both kinds of classes as Categories for the page (hence my piqued email to at least define existential classes in a separate namespace from category). So if no distinction is made, then multiple "types" are indeed necessary. If a distinction between nouns and adjectives is made, then one type + multiple facets is necessary. -----Original Message----- From: John McClure [mailto:jmcclure@hypergrove.com] Sent: Thursday, April 05, 2012 7:08 PM To: Wikidata (E-mail) Subject: [Wikidata-l] Namespace-based model Denny said: I think the assumption everything has exactly one type is oversimplifying The assumption that everything is of multiple types is over-complicating. Usually you can tell from the first sentence in the Wikipedia page. "Tuesday is a day of the week" "Love is an emotion" "(Roman) Catholicism is a faith" "Gollum is a fictional character" "HAL-9000 is a character" "Noah is a Patriarch" "Enos was the first chimpanzee" So consensus certainly is being achieved among thousands of authors about the fundamental type of thing each of these pages represent. Disambiguation pages very commonly reference these types of things as in "Enos (chimpanzee)". Let's take Gollum. I can imagine a topic map has these subjects: 1. Character 1A. Fictional character 1A1. Fictional person 1A2. Fictional animal 1A3. Fictional ghost 1A4. Fictional god Another equally valid assertion is that Gollum is a Character that is typed as Fictional and Human thing (both these adjectives that are instances of owl:Class) -- so that a comprehensive system sometime in the future would reinterpret that Gollum is actually a Fictional person. As you say yourself, it's not useful to create a "perfect" system to handle every imaginable edge case **to the extent that they exist**. Personally I don't believe such edge cases can be found - I challenge anyone to provide me such an example. But more to the point of Wikidata. I don't believe for a second that WP will be reorganized into thousands of namespaces. Rather, I believe first, SUBOBJECT names must include the idea of 'namespace' for the efficiencies gained, and second, WP pages should be associated with the same set of nouns (noun-phrases) available for subobject names. IOW, it's an implementation issue whether a wiki's pages are named using these namespaces, so that the wiki as a whole can gain the same inherent efficiencies I've sketched for subobjects. Best - john

1 0

[Wikidata-l] Namespace-based model
by John McClure 06 Apr '12

06 Apr '12

Denny said: I think the assumption everything has exactly one type is oversimplifying The assumption that everything is of multiple types is over-complicating. Usually you can tell from the first sentence in the Wikipedia page. "Tuesday is a day of the week" "Love is an emotion" "(Roman) Catholicism is a faith" "Gollum is a fictional character" "HAL-9000 is a character" "Noah is a Patriarch" "Enos was the first chimpanzee" So consensus certainly is being achieved among thousands of authors about the fundamental type of thing each of these pages represent. Disambiguation pages very commonly reference these types of things as in "Enos (chimpanzee)". Let's take Gollum. I can imagine a topic map has these subjects: 1. Character 1A. Fictional character 1A1. Fictional person 1A2. Fictional animal 1A3. Fictional ghost 1A4. Fictional god Another equally valid assertion is that Gollum is a Character that is typed as Fictional and Human thing (both these adjectives that are instances of owl:Class) -- so that a comprehensive system sometime in the future would reinterpret that Gollum is actually a Fictional person. As you say yourself, it's not useful to create a "perfect" system to handle every imaginable edge case **to the extent that they exist**. Personally I don't believe such edge cases can be found - I challenge anyone to provide me such an example. But more to the point of Wikidata. I don't believe for a second that WP will be reorganized into thousands of namespaces. Rather, I believe first, SUBOBJECT names must include the idea of 'namespace' for the efficiencies gained, and second, WP pages should be associated with the same set of nouns (noun-phrases) available for subobject names. IOW, it's an implementation issue whether a wiki's pages are named using these namespaces, so that the wiki as a whole can gain the same inherent efficiencies I've sketched for subobjects. Best - john

1 0

Re: [Wikidata-l] SNAK -> assertion?
by John McClure 06 Apr '12

06 Apr '12

Hi Denny - Correct - URI opaqueness is required at the level of exchange but there's no such requirement internal to an application. During exchange, sure you can add a triple to assert that Density is the type of the object France#Density:2012_pop_estimate_Bilan_2010. Outside of exchange, type can be reported by an API or template which parses the namespace from the object's name. Obviously this would save one triple per object and per page, in the triples database - a big win in large datasets such as WP. A similar situation is found today in SMW applications. People create namespaces and then add a category of the *same name* to the pages and objects in that namespace; it's highly inefficient and makes me yelp !! Denny asks: How do I know the relationship between France#Density:2012_pop_estimate_Bilan_2010 and Germany#Density:2009_pop_estimate_CIA_2010? If you're asking how do you know they're both Density objects. That's easy - they're subobjects in the same 'namespace'. So in SMW speak, I'd like to use a predicate 'like' operator. To list all Density subobjects is just [[~#Density:+]] To list all for a page is just [[~France#Density:+]] To list all for both is [[~France#Density:+||~Germany#Density:+]] With regard to rdf:property - I think you may have meant rdf:predicate as there's no rdf:property I could find. It's domain is an rdf:Statement not rdf:Resource. Is a Snak a subtype of rdf:Statement? Why not name it as such, eg "WMFStatement", to clearly assert its lineage? In any event, I'm concerned about using rdf:predicate in this manner. In fact I suspect there's some confusion about reification, because I used dc:Subject / dc:subject to associate the 'reifier' with the object I think in a quite traditional uncontroversial manner. To use rdf mechanisms for reification in this context I'm worried could be particularly problematic. john PS yes I was giving triples!!!!

1 0

Re: [Wikidata-l] (no subject)
by John McClure 06 Apr '12

06 Apr '12

1 0

Re: [Wikidata-l] Type namespace
by John McClure 06 Apr '12

06 Apr '12

Denny said: "if I understand topic maps correctly it should be trivial to write a transformer that takes the export that Wikidata will offer and translates it into topic maps, if you are so inclined. This way the topic maps community can be served through that transformer easily, be it a web service or a parser-front-end" Sure, at a technical level, but let's focus on concepts & requirements though because your semantics may force mapping SNAKs to other protocols, bad karma for lossless exchange. And allow me to note that the "topic map" community is one & the same here as the "semantic" community (if not the greatest part of that community btw) so please, let's not create a we-they paradigm okay? I guess you know that Drupal is incorporating ISO Topic Maps and that ISO Topic Maps is a superset of the W3 RDF. It's definitely heartening to see your own evolution on this matter, creating a conceptual design so duplicative of this international standard (you can reach farther when standing on the shoulders of giants...). Last point, on the "information sources must be free" dictum, which you stated in your reply. ISO has a simple business model that is fair honest etc, to support its own non-profit operations. You can use their info for free. That said, can you provide a link to your stated policy, stated as an MWF policy, or is this your own policy -- I'd like to know more about the thinking behind it. Thanks - john

1 0

Re: [Wikidata-l] SNAK -> assertion?
by John McClure 06 Apr '12

06 Apr '12

Denny said: you forgot to add something like France#Density:2012_pop_estimate_Bilan_2010 property Density . No I did not forget anything, given the Density 'namespace' in the subobject name. IOW your triple merely restates what is discernible from the subobject name. Maybe you should tell me what a "property" property is supposed to represent At most I made a misstatement that "Estimated is an adjective treated as a subclass of owl:Class" It should say "as an instance of owl:Class"

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikidata