Hi emijrp,
I will have to investigate the licensing computability. Looking at the
wikidata site on meta, it only mentions that " The content in Wikidata
will be made available under a free license." [1] Are there any more
decisions so far on this topic or will any CC license do?
[1] http://meta.wikimedia.org/wiki/Wikidata/Notes/Requirements
Best,
Max Klein
Wikipedia in Residence
kleinm(a)oclc.org
+17074787023
Hi Max;
Is WorldCat aware of the Wikidata free license?
I think that it is a good idea to include that info in Wikidata, that
and
the DOI metadata, which is currently generated like this[1] (only
available
in English Wikipedia).
Regards,
emijrp
[1] https://en.wikipedia.org/wiki/Category:Cite_doi_templates
2012/5/25 Klein,Max <kleinm(a)oclc.org>
> Hello Wikidata Wizards,****
>
> ** **
>
> Phoebe Ayers from the Board recommended I talk to you. My name is Max
> Klein and I am the Wikipedian in Residence for OCLC. OCLC owns
Worldcat.org
> the world?s largest holder of Library data at 264 million
bibliographic
> records about books, journals and other library items. We would really
like
> to partner with you as Wikidata is being built, in incorporating our
data
> into your project.****
>
> ** **
>
> *What we can offer:*
>
> **? **WorldCat.org metadata http://www.worldcat.org/ . ****
>
> **o **Typically, for any work we have most of the following: title,
> authors, publisher, formats, summaries, editions, subjects, languages,
> intended audience, all associated ISBNs, length, and abstract.****
>
> **? **APIs to this data http://oclc.org/developer/****
>
> **o **And some other cool APIs like xISBN which returns all the
ISBNs
> of all the editions of book on the input of any single one.****
>
> **? **Library finding tools****
>
> **o **When viewing a record on our site, we show you the closest
> library which has that work, and links to reserve it for pick-up.****
>
> **? **The Virtual International Authority File (VIAF)
> http://viaf.org/, which is an Authoritative Disambiguation file****
>
> **o **That means that we have certified data on disambiguation of
> Authors****
>
> **? **WorldCat Identities, an Analytics site
> http://www.worldcat.org/identities/****
>
> **o **It gives you for Author metadata and analytics: Alternative
> names, significant dates, publication timelines, genres, roles,
related
> authors, and tag clouds of associated subjects.****
>
> ** **
>
> *What?s in it for us:*
>
> **? **We are a not-for-profit member cooperative. Our mission
is
> ?Connecting people to knowledge through library cooperation.?****
>
> **? **Since I work at the research group, for now this is just
a
> research project.****
>
> **o **If at some point this goes live - and you want to - we?d like
to
> integrate the ?find it at a library near me? feature, that means
> click-throughs for us.****
>
> ** **
>
> *The ideas:*
>
> There are a lot of possibilities, and I?d like to hear your input.
These
> are the first few that I?ve can come up with.****
>
> **? **Making infoboxes for each book or author that contains
all
> their metadata.****
>
> **o **Ready to incorporate into all language projects.****
>
> **? **Using authority files to disambiguate or link works to
> their creators.****
>
> **o **Solving DABs****
>
> **? **Using our analytics (e.g. author timelines) as Wikidata
> data types to transclude.****
>
> **o **Curating articles with easy to include dynamic analytics****
>
> **? **Populating or creating works/author pages with their
> algorithmically-derived history and details.****
>
> **o **Extremely experimental semantic work.****
>
> ** **
>
> I?m roaring and ready to get this collaboration going. I know Wikidata
is
> at an early stage, and we are willing to accommodate you.****
>
> Send me any feedback or ideas,****
>
> ** **
>
> Max Klein****
>
> Wikipedia in Residence****
>
> kleinm(a)oclc.org****
>
> +17074787023****
>
> ** **
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
--
Emilio J. Rodr?guez-Posada. E-mail: emijrp AT gmail DOT com
Pre-doctoral student at the University of C?diz (Spain)
Projects: AVBOT <http://code.google.com/p/avbot/> |
StatMediaWiki<http://statmediawiki.forja.rediris.es>
| WikiEvidens <http://code.google.com/p/wikievidens/> |
WikiPapers<http://wikipapers.referata.com>
| WikiTeam <http://code.google.com/p/wikiteam/>
Personal website: https://sites.google.com/site/emijrp/
Hey :)
This is the Wikidata summary of the week before 2012-05-25.
You can also find this at
http://meta.wikimedia.org/wiki/Wikidata/Status_updates/2012_05_25
= Development =
* Reworked our git workflow:
http://meta.wikimedia.org/wiki/Wikidata/Development/Process
* Wrote tests for client, lib and repo
* Introduced namespaces in lib and repo
* Finished work on diff functionality which now supports recursion
* Started work on handling changes on the client and appropriately
caching info there
* Reviewed code
* Test, debug and fix problems in the Wikidata core branch
* Fixed & refactored some minor stuff in the UI
* Fixed broken UI tests
* Getting git-review running on Windows
* Trying to make all PHPUnit tests running without Failures & Errors
under Windows
See http://meta.wikimedia.org/wiki/Wikidata/Development/Current sprint
for what we’re working on next.
You can follow commits at
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/WikidataClient…
and https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/WikidataRepo.g…
(stuff not merged into master yet isn't included there)
= Discussions/Press =
* Proposal for inclusion syntax:
http://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax
* Feedback on the demo system in various places has been very positive so far
= Events =
see http://meta.wikimedia.org/wiki/Wikidata/Events
* LinuxTag
* upcoming: IRC office hours next Tuesday and Wednesday
* upcoming: MediaWiki hackathon (and Wikidata/RENDER event)
* upcoming: Admin Convention of the German Wikipedia
= other stuff =
* preparations for the hackathon and Wikidata/RENDER event next week
Anything to add? Please share! :)
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications 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.
I think this exchange with an expert of languages on-line can be of
interest to us. Discussion comes from the Unicode mailing list.
Best
Glenda.
At 16:29 25/05/2012, Philippe Verdy wrote:
2012/5/25 glenda.jerome <info(a)execlub.org>:
> At 00:15 24/05/2012, Philippe Verdy wrote:
>>
>>
>>
http://blog.wikimedia.org/2012/05/21/introducing-designs-for-the-universal-…
>> Enjoy :-)
>> -- Philippe.
>
>
> Philippe,
>
> could you please comment a little further on your comment? It would be of
> real help to people working on the Wikidata project. I personally have no
> idea why it would be a good/bad idea as I see cons and pros to the
concept.
> The real issue we have is to associate a term, its display, its exact
> meaning and its value to a linguistic community. My fear is that a term
may
> have orthoghraphic and meaning variances and that such a simplified
approach
> may errode this diversity. This is not an area where we are expert, but I
am
> aware that what may decided for a MediaWiki project may influence many
> things.
>
> Thank you!
> Glenda
I did not want to be obtrusive when posting this URL. But the current
project in the Wikimedia foundation certainly has many valuable
contributors available that could criticize the concepts and help
defining it more precisely.
But if the intent is to create associations of terms across languages,
the difficulty is several orders of magnitude higher than doing that
only within the same language.
For now there are manual tuning to help create interwiki links, but we
all know that these links are not (and cannot) be completely
transitive, include for the reason that articles on each wiki have
different structures and coverage of their subject (and it's irrealist
to have as many articles with exactly the same coverage across all
languages). So articles are splitting their subjects differently :some
wikis will group several subjects with similar names on the same page,
some will be so developed that they will be separated.
In my opinion, the only safe interlingual classification that works is
the one used in Commons (but Commons does not cover all subjects found
in other wikis, it is poor about history, linguistic, politics, music,
cinema, books and comics, and advanced sciences for example, because
it is difficult to illustrate many concepts distinctly with images,
audio or videos.
So instead, I would build a dedicated search engine that can search
through existing interwiki links and find associations, and possibly
develop some automatic translation tools, or text extractors that can
be used to compare contents from the various projects.
Hey,
Hope these are of use to others as well :)
* http://bit.ly/wdreview - Our review queue for the Wikibase extensions
(should be short!)
* http://bit.ly/wdchanges - Open and merged changes to the Wikibase
extensions, gives you an idea of who has been doing what
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Regarding the translation of wikibase-api-aliases-invalid-list, would it work to use an translation instead of one of the three parameters.
Example: "Ajouter" is defined in wikibase-add as the french translation of "add". If "ajouter" would be used instead of "add" as an parameter in the API, would that work?
Dear all,
Comments are welcomed about a page I just posted which
posits the use of the topic map metamodel (TMM) in the wikidata project.
I'll do my best to respond, but frankly my focus these days is on more
mundane topics like simple survival.
Cheers - john
Belltower Wikis
On 22.05.2012 15:15, Nikola Smolenski wrote:
> Including Items in an Article:
>
> {{#data-template:Infobox
> |data_item=q332211
> |data_param=stuff
> |foo=some value
> |stuff.color=green
> }}
>
> I see no reason for creating a new parser function for inclusion of templates.
Basically, we need a way to pass a complex data object as a parameter to a
template. If we don't have that, we have two alternative choices:
1) assign per-page variables to items, e.g. make {{{thingy}}} available in the
article after a call to {{#load-data|thingy}}. Then you can use
{{Infobox|data={{{thingy}}}}}, as usual. But I think this "global variables"
approach is ugly and confusing, at least when stuff is loaded from inside templates.
2) alternatively, don't pass item from the article to the template at all.
Instead, use parser functions for every access to an item property, and specify
the item id as a parameter if necessary. That would create a lot of rundundancy
and wouldn't allow "normal" template parameter syntax to be used to access data
properties.
To me, this seems natural, because it behaves like a function call. Being able
to pass complex objects as parameters directly would of course be better still.
Actually, if the template in question wants to pass the data object on to
another template, we kind of need this...
> Also, this syntax would not allow a template to draw data from more than one
> item
Correct. This could be simple enough to overcome, though I can't think of a
*nice* way off hand. Off the top of my head, I'd do something like this:
...
|data_item_2=q556677
|data_param_2=other_stuff
|data_item_3=q114488
|data_param_3=more_stuff
...
or even:
|data_item=q332211 as stuff
|data_item_2=q556677 as other_stuff
|data_item_3=q114488 as more_stuff
> which would probably be a requirement in phase3.
No, it's not. phase3 is about automatic listings, which require a different
syntax anyway. Also, in a list, all items would use the same template and the
same rendering options. No need for the ability to pass multiple items to a
single template.
> Rather, I would include a template normally and use a parser function within the
> template to access the data.
So, that would be option (2) from above.
> So, instead of {{{data}}} there would be {{#data:}}, instead of {{{data.color}}}
> there would be {{#data:color}}, instead of {{{data.color(ACME_SURVEY_2010)}}}
> there would be {{#data:color|ref=ACME_SURVEY_2010}} and so on.
How would you specify which item {{#data:}} refers to, in case it's not the
articles "default" item? How would you pass multiple items to a template?
> One advantage is that commonly used syntax is always used, instead of inventing
> new syntax (as for the reference in this example).
For the most part, I tried to keep the normal syntax for template parameters,
just introducing structured names (dots and colons). The syntax for
selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop it.
If this is needed, one can always use the {{#data-value}} function with
source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').
> Another advantage, this way would make data usable directly in article text, if
> that is wanted.
Yes, that's also something that is bothering me. I would propose for this case
to implement option (1) from above: use {{#load-data|stuff}} to make the item
available as {{{stuff}}} in the current scope (preprocessor frame).
That's kind of like saying "pass the item to me" instead of "pass the item to
the template".
> The parser function should be able to override itself by template parameters - I
> believe it is possible to do this.
That makes the hair in my neck stand up :)
> Unrelated to the above,
>
> "This will return the value of the color property, in the page's content
> language, as plain text."
>
> I see that there is need to also select desired content language (for example, a
> lot of infoboxes display name of the topic in the content language and in the
> topic's language(s)). This has the potential to introduce additional problems,
> of course.
The parameter syntax is the simply way to access property values. For all fancy
needs, like picking the language, use {{#data-value}} instead. Basically, the
{{{data.foo}}} syntax is just a shorthand for the more powerful {{#data-value}}
stuff.
Except that it's not wrapped in any HTML. Perhaps there should be an option to
{{#data-value}} to turn that off completely, using form=plain or some such.
> form
> Specifies in what form rendered, that is, in which HTML element the value
> should be wrapped.
>
> span: wrap in <span> tags, use <span> tags for parts
> div: wrap in <div> tags, use <span> tags for parts
> li: wrap in <li> tags, use <span> tags for parts
>
> I don't like this at all, since it limits the number of possibilities,
> introduces yet another syntax parallel to HTML.
>
> Yet, I don't see anything much better. A half-baked idea is to leave it to the
> client wikis to create their data display templates that could be used to format
> data appropriately.
Yes, this is kind of a nasty compromise.
On the one hand, it would be extremely cumbersome to have to re-implement the
table (and other) structures for representing property values with various
qualifiers, not to speak of the rendering logic for these qualifiers themselves.
On the other hand, we want to allow template authors to integrate property
values in different kinds of structures, like tables and lists.
Note that with the help of the show=... parameters, template authors can still
implement their own rendering of the value (or rather, statement) with all it's
parts, using one {{#data-value}} call for each one.
>
> (I see Jérémie's email now, and see that we came independently to some of the
> same conclusions :) )
>
> {{#data-values}}:
>
> But this is of course an even worse problem.
>
> {{#data-link:data|the data item}}
>
> Why not the usual interwiki syntax of [[wikidata:data|the data item]]?
because "data" is not an identifier for that item on the wikidata repo. YOu
would have to use something like:
[[wikidata:/id/{{{data.id}}}|the data item]]
But constructing edit links this way is very cumbersome. The main intend for
this function is to make it easy to provide an edit link in the infobox.
But perhaps a different syntax should be used for this. After all, the edit link
would, with javascript enabled, not really be a link, but a button to activate
the on-site editing feature.
Thanks for your comments!
-- daniel
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de | Tel. (030) 219 158 260
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.
(Once Wikidata seems to be a german project, I'll write this mail also in
german language. Let me know if I'm wrong, so I would write again in
english)
Hallo
Ich bin sehr an der Teilnahme vom Wikidata-Projekt interessiert, kämpfe
aber noch mit der richtigen Anlaufstelle, bzw. Informationsbeschaffung.
Natürlich habe ich die Informationen unter
http://meta.wikimedia.org/wiki/Wikidata
(http://meta.wikimedia.org/wiki/Wikidata) sowie einigen der Unterseiten
gelesen. Eine Anfratge unter #wikimedia-wikidata
(irc://irc.freenode.net/wikimedia-wikidata) wurde obschon etwa 30
Teilnehmer online waren nicht beantwortet. Deshalb nun meine Anfrage über
die Mailingliste.
Soweit ich gesehen habe, gibt es eine Liste in der man sich als Helfer
eintragen lassen kann (http://meta.wikimedia.org/wiki/Wikidata/Volunteers
(http://meta.wikimedia.org/wiki/Wikidata/Volunteers)). Allerdings sind mir
die Aufgaben nicht ganz klar. Was genau man also z.B. unter "Interwiki to
wikidata transition", "Importing data to Wikidata" oder "Infobox
transition" zu verstehen hat. Solange ich darüber nicht im klaren bin,
kann ich mich leider nicht eintragen. Könnte mir jemand beschreiben was
genau man unter diesen drei Begriffen zu verstehen hat, wie die Arbeit
daran genau aussieht und ab wann man mit der Arbeit loslegen kann?
Ich würde mich gerne in irgendeiner Form der Dateneingabe-/übernahme
beteiligen. Entweder die direkte Dateneingabe/-import, oder die nötigen
Vorbereitungen dazu, damit der Import automatisiert werden kann. Welche
Arbeit wäre da für mich passend?
Freundliche Grüsse
Tobias
Heya folks :)
We've worked on mockups for how we think linking of articles between
different Wikipedias should work with Wikidata. You can find the
mock-ups and explanations here:
https://meta.wikimedia.org/wiki/Wikidata/Notes/Storyboard_for_linking_Wikip…
It'd be great if you could have a look and give feedback either here
or on the discussion page on meta.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications 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.
Heya folks :)
I’m happy to let you know that we now have a demo system where you can
follow Wikidata development hands-on. The demo system will be updated
regularly so you can always see what we’ve been up to and try it out
yourself.
Please keep in mind that this is a system for testing so things might
and probably will break here and there. There will be bugs. If you
find any of them please tell us. There will be missing features or
things that are not really finished yet. Data in there can be deleted
at any time. That being said we hope that this gives you a good view
of where Wikidata is heading and an opportunity to try it out and give
feedback before it gets deployed.
Right now you'll only see the start of the interwiki-link part of
Wikidata. This means there is a repository where the links are
collected and stored and a client that uses them.
We’re looking forward to your feedback. For small comments please use
the feedback link at the top of each page. For bug reports please use
http://bugs.wikimedia.org (component Wikibase Client or Wikibase Repo
in the product MediaWiki Extensions) and mention any information that
might be relevant. And you’re of course free to discuss on this list.
Thanks for your help with testing this. Your feedback is important to
make Wikidata successful.
You can access the demo at http://wikidata-test-repo.wikimedia.de.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications 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.