Hello,
I am interested in contributing time to the Wikidata project. I'm CTO for a
consulting company in Ohio (USA), and come from a custom application
development background. I have a strong background in web applications and
relational databases, and have been recently working with non-relational
databases, mobile applications and distributed data tools (ie Hadoop).
I am relatively new to the semantic web area, but would like to find a way
to help with the project. It would seem logical to try to help with coding
and / or documentation type tasks, but I'm open to suggestions. I read
through the the project info and FAQs. Per
http://meta.wikimedia.org/wiki/Wikidata/FAQ#How_can_I_get_involved.3F, I'm
asking how I can help.
-Tim Hoolihan
Twitter: thoolihan
Freenode: thoolihan
Hi all,
now, that the project starts (HURRA!!) I think that more postings will
be expected soon.
Any chance to add this mailinglist to Gmane?
Thanks a lot. Best regards
Raimond.
--
Raimond Spekking, Köln
GPG-Schlüssel-ID: 0xB12BE7A6
Hilf mit, dass WIKIPEDIA von der UNESCO als erstes digitales Weltkulturerbe anerkannt wird. Unterzeichne die Online-Petition: https://wke.wikimedia.de/wke/Main_Page?uselang=de
On Mar 28, 2012, at 19:33 , JFC Morfin wrote:
> At 18:10 28/03/2012, Ivan Herman wrote:
>> Obviously, you all expect me to agree with Martynas, in view of my job, and I do:-). But I do not only because I work for W3C, but I indeed genuinely believe that reinventing things here may be way too costly on long term...
>>
>> Note also that W3C may start a new group later this year that would look at a 'lower' level HTTP protocol to manage (read and write) RDF data without necessarily using SPARQL. This may be useful for the project as well.
>>
>> Ivan
>>
>> On Mar 28, 2012, at 18:02 , Martynas Jusevicius wrote:
>>
>> > Hey all,
>> >
>> > I've been reading some of the technical notes on Wikidata, for example
>> > http://meta.wikimedia.org/wiki/Wikidata/Notes/Data_model
>> > http://meta.wikimedia.org/wiki/User:Nikola_Smolenski/Wikidata#Query_language
>
> I would suggest that at this stage we need to have a comprehensive understanding of all the possible options.
>
> 1.Has someone published as page listing the best *summary* documenting and argumenting each of the existing options. I suppose we will want a table indicating which existing solution answers which listed need?
>
> 2. Since we have a W3C expert: what is the best document/book to get a comprehensive and clear (not too massive) documentation on the semantic web?
>
The one which is probably closest to what WikiData would need is "Linked Data: Evolving the Web into a Global Data Space", by Tom Heath and Christian Bizer.
It is actually readable in HTML freely:
http://linkeddatabook.com/editions/1.0/
For a more complete list of books, see also
http://www.w3.org/2001/sw/wiki/Books
> 3. What are the relations with the JTC1/SC32/WG2? Is investing time in their documents appropriate?
Honestly, I do not know. The JTC1/SC32 has no link to WG2, and none of their documents are public:-(
Ivan
>
> Thank you!
> jfc
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
----
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
Hi all,
Wikimedia Germany is sending out a press release about Wikidata today. The
press release sums up the information that has been published on Meta since
last Wikimania, where it has been first presented, and discussed and
refined since then, including information about the donation that is making
Wikidata possible.
<http://www.wikimedia.de/wiki/Pressemitteilungen/PM_3_12_Wikidata_EN>
We are very excited about the Wikidata development team starting on Monday.
This also means, that in the future we will be communicating about Wikidata
much more, as the development is finally starting. Yay!
I want to take this opportunity to thank the donors of Wikidata, the Allen
Institute of Artificial Intelligence ai2, the Gordon and Betty Moore
Foundation, and Google for the generous support, that enables us to work on
the Wikidata project for the next year.
Exciting times are waiting for us, Cheers all,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hey all,
I've been reading some of the technical notes on Wikidata, for example
http://meta.wikimedia.org/wiki/Wikidata/Notes/Data_modelhttp://meta.wikimedia.org/wiki/User:Nikola_Smolenski/Wikidata#Query_language
Statements like "[data model] similar to RDF, but allows qualified
property values" and "should there be a query language that will
enable querying of the data?" concern me a great deal regarding the
future of the whole Wikidata project.
It seems to me that whoever is making these technical decisions does
not fully realize the price of reinventing the bike -- or in this
situation, reinventing data models/formats/standards. Having designed
and implemented production-grade applications both on RDBMSs, XML, and
RDF, I strogly suggest you should base Wikidata on standard RDF.
I know some/most of you are coming from the wiki background which
might be hard to get over with, but if Wikidata is to become a free
and open knowledge base on the (Semantic) Web, then RDF is the free
and open industry standard for that. Whatever little advantage you
would get from developing a custom non-standard data model, think how
many man-years of standardization and tool development you would
loose. Isn't knowledge about standing on the shoulders of giants? RDF
has all the specifications, a variety of tools, and DBPedia as a very
solid proof-of-concept (which I also think should be better integrated
with this project) necessary to build Wikidata.
With SPARQL Update, full read/write RDF roundtrip is possible (and
works in practice). It also makes the notion of API rather obsolete,
since SPARQL Update (and related mechanisms) is the only generic
API-method one has to deal with.
To round up -- I think failure to realize the potential of RDF for
Wikidata would be a huge waste of resources for this project,
Wikipedia, and the general public.
Martynas
graphity.org
Hi, my name is Patricio Molina ([[user:Mahadeva]]) and I'm interested
in open data and the potential Wikidata project.
Some info about me:
* I edit Wikipedia since 2005
* I'm an administrator (bureaucrat/sysop) in the Spanish Wikipedia
since December 2006
* I have co-founded Wikimedia Argentina (WMAR) in 2007
* Member of the Board in WMAR (2007-2009 and 2011-2013)
* Member of Wikimedia Chile (WMCL) since its creation in 2011
* Working on the foundation of Wikimedia Bolivia (WMBO), alongside
[[meta:User:Alhen]], [[meta:User:Jduranboger]] and others.
* Elected member of Wikimedia Iberocoop, representing Wikimedia
Argentina since 2012
* Technical lead in WMAR, WMCL, WMBO and Wikimedia Iberocoop
* Longtime MediaWiki user, also participating in extension development
* I'm recently participating in the Open Knowledge Foundation's lists
I'll be pleased to give a hand in anything you need!
Cheers
--
Patricio Molina
http://twitter.com/patriciomolina
It could be interesting to check out if any of the standards published
by ISO/TC 37 (http://en.wikipedia.org/wiki/ISO/TC_37) apply to this
project, like
* ISO 12620:2009 Terminology and other language and content
resources—Specification of data categories and management of a Data
Category Registry for
* ISO 12200:1999 Computer applications in terminology —-
Machine-readable terminology interchange format (MARTIF) —- Negotiated
interchange
* ISO 16642:2003 Computer applications in terminology —- Terminology
Mark-up Framework (TMF)
There could be others in addition to these.
John
Markus-
Congrats because SMW 1.7 is a real bellringer - can't wait to upgrade. I was
thinking that "named subobjects" can parallel wiki pagenames,
[[#interwiki:en:ns:pgnm]]. Some namespaces would be nice to reserve would
be #Dublin Core:, #OWL:, #SKOS:, #Topic Map: etc and their information
elements easily defined. And should SF be able to associate forms with
subobject namespaces (and categories), it seems a page can maintain a
virtual wiki. What a coup!
Topic maps distinguish type, subjects, scopes, names, associations &
occurrences - an ISO model of an index at the back of any reference book. A
minimalist implementation is to associate subjects, like categories, in a
page's #DublinCore:Subject property. Subjects can be SKOS objects defined in
Subject: namespace, where eg the Library of Congress Subject Headings are
defined. Markup is just [[Subject:subjectname]] on any page or within any
subobject. [By within, I mean a #^text property for content that's copied
into a page should it be "moved" from subobject to page -- this text can
contain category and subject markup too]. To be fully wiki,
{{pgnm#DublinCore}} might transclude the same material as
{{pgnm/DublinCore}} using this #^text property.
Their idea of "type" in <xtm:scope>:<xtm:type>:<xtm:name> maps to wiki
namespaces more naturally than categories can. Today, categories confuse
plural lists of things with singular types of thing, causing a few practical
problems. Singular nouns seem best defined in Type namespace with instances
located in an appropriately named MW namespace or MW namespace alias. Note,
MW can handle 64K namespaces, maybe for a seriously good dictionary of
common nouns and noun-phrases like Wiktionary?
A few grammatical ideas. A tilde unary operator that does a "like" page or
object selection, and filters for categories and subjects that apply to
pages & subobjects alike, seems valuable. A magic word {{ANAMESPACE}} ("A"
prefix = "A-box") might be nice too to identify a subobject's namespace.
page filters
[[~{{FULLPAGENAME}}#DublinCore:]]
[[Category:Active]][[Subject:LCSH Science]]
subobject filters
[[~{{FULLPAGENAME}}#DublinCore:]]
[[#Category:Active]][[#Subject:LCSH Science]]
both filters
[[{{NAMESPACE}}:+]]
[[Category:Active ]][[Subject:LCSH Science]]
[[#Category:Active]][[#Subject:LCSH Science]]
One alternative subobject naming is {{FULLPAGENAME}}#{{FULLPAGENAME}} which
is a Dublin Core object ie [{{FULLPAGENAME}}#{{FULLPAGENAME}}]
|?Contributor|?Coverage...|?Subject|?Title|?Type
So [[Subject:pgnm]] markup for a page can be stored in the Subject property
in a {{FPN#FPN}} or {{FPN#DublinCore}} object. Another approach is that
mediawiki build a Category-like mechanism, with its own set of tables and
indexes, for Subjects. This may boil down to which part of the wiki stack a
[[Subject:pgnm]] tag best processed. I think a [[Subject:pgnm]] could be a
useful addition to wiki markup so I hope that doesnt get obscured. Wikidata
may want to incorporate ideas concerning Topic Maps - strategically it's
possibly an easy big win, so I'll bother them too.
>-----Original Message-----
>From: Markus Krötzsch [mailto:markus@semantic-mediawiki.org]
>Sent: Wednesday, March 21, 2012 7:43 AM
>To: jmcclure(a)hypergrove.com
>Subject: Re: [Wikitech-l] Topic Maps
>
>
>On 21/03/12 13:06, John McClure wrote:
>> (1) official ISO versions are purchaseable while unofficial
>versions are
>> foss.
>
>Ok, that's a pity. A standard that nobody can read is not so
>helpful ...
>We already had this issue with other ISO standards before. In the end,
>people just ignore them because they do not get to them.
>
>> (2) there is a TMAPI which I think is conceptual not a
>software library. Use
>> XML parser.
>
>I was more thinking of a library to represent and manipulate
>topic maps
>in a program. Parsing it is one thing, but representing TMs as
>a kind of
>DOM tree (that you would get from XML) would not be so great I guess.
>
>> (3) Drupal has an extension now. There are a few others.
>> (4) again, there's a QL but it's far more SQL - check it
>with XTM for data
>> structures.
>
>Ok, so there is a standard mapping from TM to RDB that allows
>SQL to be
>used for querying?
>
>> Personally, topic maps should be implemented in WP using
>SMW's subobjects.
>
>Ah, so I suppose you are viewing TMs more as a kind of
>conceptual model
>than as a concrete standard with a fixed syntax/semantics. Fair enough.
>
>Regards
>
>Markus
>
>>
>>> -----Original Message-----
>>> From: Markus Krötzsch [mailto:markus@semantic-mediawiki.org]
>>> Sent: Wednesday, March 21, 2012 3:28 AM
>>> To: jmcclure(a)hypergrove.com
>>> Subject: Re: [Wikitech-l] Topic Maps
>>>
>>>
>>> [Off-list, maybe off-topic too ;-)]
>>>
>>> Hi John,
>>>
>>> I would actually like to learn a bit more about topic maps.
>Could you
>>> maybe help me to answer some of the following questions?
>>>
>>> (1) Where can I see the official standard? All the documents that I
>>> found start by saying that they are not the ISO standard.
>Where is the
>>> official spec?
>>>
>>> (2) Which software libraries support topic maps? (parsing,
>API, etc.)
>>> For which other tasks is there support in existing software
>(authoring
>>> tools? database systems? reasoners?).
>>>
>>> (3) What are the major users of topic maps today? Where are
>they used?
>>>
>>> (4) How does one query information that is stored in topic maps? (In
>>> other words: which kinds of data access are supported?)
>>>
>>> Thanks,
>>>
>>> Markus
>>>
>>>
>>> On 21/03/12 00:53, John McClure wrote:
>>>> Adding Topic Maps to MW base software could be a winner --
>>> it can generate a
>>>> wiki-site map (some think WP needs one!); it can be used to
>>> corelate the
>>>> contents of documents loaded into a wiki (like conference
>>> proceedings) with
>>>> a wiki's topic map; and would make a cool tool for any page
>>> in a wiki, most
>>>> clearly on a user page. It's perhaps a smart strategic move
>>> - ISO 82250
>>>> Topic Maps are the fruit of SGML/Hytime n-ary models that
>>> 'lost' to RDF
>>>> triples back when. Being a superset of RDF, TMs can type
>associations
>>>> between articles while capturing all infobox data.
>>>>
>>>> Topic maps may be a compelling FUNCTIONAL upgrade for MW as
>>> it captures
>>>> subjects of an article for the first time. Given topic-map
>>> to RDF transforms
>>>> amid continuing W3 research, this could be enough for the
>>> semantic world. By
>>>> adopting say the Lib of Congress' Subject Headings, a wiki
>>> like Wikipedia
>>>> could play an important role in the semantic web. The
>>> current situation with
>>>> Wikipedia is that it's hard to have a large library of
>>> information without a
>>>> subject catalogue... right now, wikis have an author
>>> catalogue sort of, fine
>>>> for smaller hadcrafted wikis but doesn't scale well for many.
>>>>
>>>> Since other platforms now have maturing topic map extensions
>>> I'm worried the
>>>> impact on wikis not to have that technology.
>>>>
>>>> John McClure
>>>>
>>>>
>>>> _______________________________________________
>>>> Wikitech-l mailing list
>>>> Wikitech-l(a)lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>>
>>>
>>
>>
>
Data Wikipedians,
The talk submission below explains my interest in structuring wikipedia
for interaction with machines, so consider it my introduction to this
list.
I hope WikiData will provide a foundation for KBA-type algorithms (see
below), and am looking forward to learning more about APIs from WikiData.
-jrf
http://wikimania2012.wikimedia.org/wiki/Submissions/TREC-KBA-Mining-Content…
TREC KBA - Mining Content Streams to Recommend Page Updates to Editors
Abstract: We have organized a new session in NIST's Text Retrieval
Conference (TREC) called Knowledge Base Acceleration (KBA). TREC KBA
challenges computer science researchers to develop algorithms that mine
content streams, such as news and blogs, to recommend edits to knowledge
bases (KB), such as Wikipedia. We consider a KB to be "large" if the
number of entities described by the KB is larger than the number of humans
maintaining the KB. As entities change and evolve in the real world, large
KBs often lag behind by months or years. Such large KBs are an
increasingly important tool in several industries, including biomedical
research, law enforcement, and financial services. TREC KBA aims to
develop algorithms for helping KB editors stay abreast of changes to the
organizations, people, proteins, and other entities described by their
KBs. In this technical presentation, we will give an overview of the TREC
KBA data sets and tasks for 2012 and future years. In addition to
developing text analytics, we are also working on a wikipedia bot for
connecting KBA-type systems to users' talk pages in mediawiki. After
presenting the current state of our bot development, we hope to engage the
audience in an open discussion about how such algorithms might be most
fruitfully employed in the Wikipedia community.
http://trec-kba.org/
(Consider putting your name on the "interested" list in the page linked
above.)