#OmegaWiki supports #OpenDyslexic

#OmegaWiki aims to be useful as a platform. Much of its functionality is in the extension that allows us to be special. The core functionality however is provided by MediaWiki. The Universal Language Selector is an extension of MediaWiki waiting in the wings to become available on all the wikis of the Wikimedia Foundation.

Part of the ULS is the use of webfonts and, OpenDyslexic is a font available for many languages that use the Latin script. Languages like English, French, German, Dutch... The font looks odd to most people but for many people who are dyslexic it makes text actually .. readable.
Thanks,
     GerardM

#Wikidata has a #homonym problem

You do not solve disambiguation in Wikidata with a "disambiguation page". It cannot be done because Wikidata supports all languages and each language has different homonyms.

The obvious solution; add a description.

When description are added, you can select the right homonym among others. When descriptions are added, you know what or who the subject is. 

When descriptions are added, you are halfway towards implementing a dictionary like OmegaWiki. What OmegaWiki has in addition to Wikidata is information about the word itself; if it is a noun and when it is, what gender it has, what its plural, diminutive etc is. Another thing OmegaWiki has are verbs and other words that typically do not get a Wikipedia article.

Guess what, Wikidata has already implemented half the features of OmegaWiki. It is not as tough to add the other half.

Thanks,

      GerardM

#OmegaWiki works and so can #Wikidata

OmegaWiki provides functionality that is on the agenda for Wikidata. The OmegaWiki community has ALWAYS wanted to be a Wikimedia project.

What it already provides is:

• links to Wikipedia articles in other languages when the article does NOT exist in the preferred language
• links to a commons category associated with a concept
• a picture painting the thousand words associated with the concept

Yes, it is quite shocking; it also provides multi lingual dictionary support. OmegaWiki has even been described in a book on the development of lexicography.

Both OmegaWiki and Wikidata are "right in front of us" and, the functionality described above is imho "right for us". The challenge we face is to do something that is "shockingly rare"; meet halfway.

The road towards such a meeting could be:

• Adopt OmegaWiki by the WMF in a labs kinda construction
• Create the logical requirements of OmegaWiki data in Wikidata
• Convert the OmegaWiki content to Wikidata technology
• See how it fits in the big picture
• Make it fit in the big picture

We do not need much talk and, the amount of work needed is relatively minor. The benefits are legion because even when all the OmegaWiki data is not used in the end, the lessons learned will be.

Thanks,

      GerardM

Machine translation for #Wikipedia

The Wikimedia Foundation suggests that machine translation is the kind of infrastructure that makes sense to it. Given what it aims to do: making knowledge available to everyone, this makes perfect sense. A lot of translation has already been going on in order to fill many gaps in the many Wikipedias and machine translations were often an important part of this.

One of the arguments why the WMF could enter the fray is that it has something to add. It does have monetary reserves but more importantly it has several resources that may make a difference. The biggest two are Wikipedia itself and the other are its awesome communities.

When translating a Wikipedia article, the concepts that are specific to a subject are likely to be found in that article. Similarly when such concepts have their own article, they will contain a similar set of concepts. Combine this with a multi-lingual dictionary build with Wikidata technology along OmegaWiki lines and it will be relatively easy to find the corresponding expressions in articles in different languages on the same subject.

The point here is that the meanings of words do not exist in a vacuum.

When such concepts have been identified and linked to Wikipedia articles and dictionary meanings it becomes possible to help people understand a text in a different language by providing native language support.

<GRIN> I know Erik Moeller has a lot of experience in this field and I know mutual friends are quite interested to help </GRIN>

Relevant is that we do not have to invent something new; it has been part and parcel of things we have done before. The difference is that we gained in experience and, technology has evolved as well.
Thanks,
     GerardM

Using #Wikidata in #OmegaWiki

Wikidata knows about the existence of #Wikipedia articles. One really nice side effect is that OmegaWiki will point you to the article in your language, Arabic in the example, even when OmegaWiki does not have a translation in your language.
Thanks,
       GerardM

#WMDEVDAYS - #OmegaWiki vs #Wikidata

It has been wonderful to see the enthusiasm in Wikidata. It is wonderful to notice how Wikidata is developing rapidly. It is interesting to look at what it does and, how it compares to the first, the original Wikidata project, OmegaWiki.

The short answer is, that there are three main differences;

• OmegaWiki uses a lexical perspective where Wikidata uses a concept like perspective
• OmegaWiki is more mature
• Wikidata has the support of the Wikimedia Foundation

Wikidata starts with the existence of Wikipedia article(s). Each one of those represents a concept. Berlin (Germany) is an example and  Berlin (Connecticut) is another. In OmegaWiki they would both be known as Berlin while in Wikidata they may both have an additional label for the English language with "Berlin" as its content.

This difference or perspective gives Wikidata an immediate application; it will replace the "interwiki links" for Wikipedia. One important benefit will be that there will be only one instance where these links are maintained. In the case of Berlin (Germany) a new article about this city will not see an update in 205 other Wikipedias. 

Both Wikidata and OmegaWiki are able to present details on Berlin. All the details at OmegaWiki have been added by hand. Most of the details Wikidata will know are likely to be harvested from info boxes or from DBpedia. What will also make a deciding difference is that the community interested in the Wikidata content will be huge.

So OmegaWiki is more mature... in practical terms it means that it started a long time ago and is now a bit dated. The Wikidata folks know OmegaWiki, they benefited from the experience and while they do not include all the data OmegaWiki has, there is nothing stopping them at a later date.

Many people at the Berlin hackathon are keenly aware of the disturbing potential of Wikidata; no more need for the pywikipedia interwiki bot. Information in info boxes change without a trace in the local project. But they also see the possibility of providing information in a language where its Wikipedia does not have an article... information with an infobox..

It is the support of the Wikimedia Foundation and more importantly its communities that will make Wikidata a success. This is a good thing because the inclusion of structured data in Wikipedia will prove a big improvement in data quality and accuracy.

Thanks,

        GerardM

Sisters are doing it for themselves

#Wikipedia has sister projects. They are mighty fine sisters too. They have their own purpose, their own communities and their own public. It is easy to argue that Wikipedia on its own will never provide people with the sum of all knowledge as Wikipedia restricts itself to encyclopaedic content.

As the siblings of Wikipedia are not getting the attention they deserve, there is now a "Sister Projects Committee" that will seek a remedy.

On the talk page many issues, opportunities are mentioned. One of them is close to my heart; it is to coordinate Wiktionary and OmegaWiki. OmegaWiki was always ready to be adopted by the Wikimedia Foundation, this never happened. Now that Wikidata is being prepared for development, it will be interesting to learn if the new project will be capable to surpass OmegaWiki in its support for multiple languages. When it does, it will be interesting to see if Wikidata is able and willing to go where OmegaWiki wants to go and share the journey.

As there are more sister projects, all with their own opportunities, it will help when they get more of the attention Wikipedians take for granted.
Thanks,
     GerardM

#Wikidata, the interview

The press release is out, the mailing lists are full of it. But what is this brand new Wikidata project about. Who better to ask but Lydia Pintscher and Daniel Kintzler. Lydia does "community communications" for the Wikidata project and Daniel has been involved in many data related projects including OmegaWiki, the first Wikidata iteration.

Wikidata is still brand new; it does not have its own logo however it is ambitious and I expect that it will improve the quality and the consistency of the data used in MediaWiki projects everywhere. Enjoy the answers to the ten questions answered by Lydia and Daniel.
Thanks,
      GerardM

What is it that Wikidata hopes to achieve?
The Wikidata project aims to bring structured data to Wikipedia with a central knowledge base. This knowledge base will be accessible for all Wikipedias as well as 3rd parties who would like to make use of the data in it.

When you express this in REALLY simple language, what is the "take home" message of Wikidata?
We are creating a central place where data can be stored. This could for example be something like the name of a famous person together with the birthdate of that person (as well as a source for that statement). Each Wikipedia (and others) will then be able to access this information and integrate it in infoboxes for example. If needed this data can then be updated in one place instead of several. There is more to it but this is the really simple and short version. The Wikidata FAQ has more details.

Structured data is very much like illustrations. The same data can be used over and over again. Will there be a single place to update for everywhere where it is used?
Yes. There will be a central place but we are also working on integrating this in the editing process in the individual Wikipedias.

This project is organised and funded by the German chapter. Will this ensure that the data can be used in many languages?
The German chapter is indeed organising it. Funding is coming from Google Inc., AI2 and the Moore Foundation. One of the main points of Wikidata is that it will no longer be necessary to have redundant facts in different Wikipedias. For example it is not really necessary to have the length of Route 66 in each language’s article about it. It should be enough to store it once, including sources for the statement, and then use it in all of them. In the end the editor will be free to decide if he or she wants to use that particular fact from Wikidata or not. This should be especially helpful for smaller
Wikipedias who can then make better use of the work of larger Wikipedias.
In order to make the data useful in pages written in different languages, we of course have to provide a way to supply information in different languages. This is described in more detail below.

In new Wikipedias a lot of time is spend in localising info boxes. Will Wikidata make this easier?
The template for the infobox still has to be created by the respective Wikipedia community -- but filling the infoboxes would be much easier! Wikidata could be used to get the parameters for the infobox templates automatically, so that they do not need to be provided by the Wikipedians.
    Lydia

Will it be possible to associate the data with labels in many languages? 
Each entity record can have a label, a description (or definition) and some aliases in every language. Not only that: each language version of the label can have additional information like pronunciation attached. For example, the record representing the city of Vienna may have the label “Vienna” in English and “Wien” in German, with the respective pronunciations attached (/viːˈɛnə/ resp [viːn]).

Many people who are part of the project have a Semantic MediaWiki background. How does this affect the Wikidata project? 
Wikidata will profit from the team’s experience with Semantic
MediaWiki in two ways: they know what worked for SMW, and they know what caused problems. We plan to be compatible to the classic SMW in some areas: for instance, we plan to re-use SMW plugins for showing query results. On the other hand, we will use a data model and storage mechanisms that are more suitable to the needs of a data set of the style and size of Wikipedia.

To what extend will Wikidata data be ready to be expressed in a "semantic" way and if so what are the benefits?
Wikidata will only express very limited semantics, following the linked data paradigm rather than trying to be a true semantic web application. However, Wikidata will support output in RDF or the resource description framework, albeit relying on vocabularies of limited expressiveness, such as SKOS.

The DBpedia project extracts data from the Wikipedias. To a large extend this is the same data Wikidata could host. Is there a vision on how Wikidata and DBpedia will coexist?
If and when all structured data currently in Wikipedia is maintained within Wikidata, the extraction part of DBpedia will no longer be necessary. However, a large part of DBpedia’s value lies in the
mapping and linking of this information to standard vocabularies and data sets, as well as maintaining a Wikipedia-specific topic ontology. These things are and will remain very valuable to the linked data
community.

You worked on the first Wikidata iteration; OmegaWiki. What is the biggest difference ?
The idea of Wikidata is quite similar to OmegaWiki - it’s no coincidence that the software project that OmegaWiki was originally based on was also called “Wikidata”. But we have moved on since the
original experiments in 2005: The data model has become a bit more flexible, to accommodate the
complexity of the data we find in infoboxes: for a single property, it will be possible to supply several values from different sources, as well as qualifiers like the level of accuracy. For instance, the
length of the river Rhine could be given as 1232 km (with an accuracy of 1km) citing the Dutch Rijkswaterstaat as of 2011, and with 1320 km according to Knaurs Lexikon of 1932. The latter value could be marked as deprecated and annotated with the explanation that this number was likely a typographical error, misrepresenting earlier measurements of 1230 km.
This level of depth of information is not easily possible with the old Wikidata approach or the classic Semantic MediaWiki. It is however required in order to reach the level of quality and transparency
Wikipedia aims for. This is one of the reasons the Wikidata project decided to implement the data model and representation from scratch.
     Daniel

2000

April 9, 2005 knew the first blog post and today I celebrate blog post no 2000. At the time I announced that I would promote the good cause of the "ultimate wiktionary" now OmegaWiki and at this time it has broadened to the support of Wikis, languages and things I find relevant.

Blog post no 1000 was only two years ago and number 1500 was in Februari last year. According to Blogger there have been 211143 page views and given that my blog is also aggregated the true number of page views must be larger. What matters to me is that the message of languages and language support is getting its public.

Seven years ago, supporting other languages was not considered much of a priority; support was very much focussed on Wikipedia and European languages at that. Nowadays, language support is provided in MediaWiki itself by a development team and the support includes localisation, support for gender, plural and grammar in messages, web fonts, input methods, direction.

With the increased support for languages we are getting more and more a situation where it is almost as easy to edit MediaWiki in most languages as it is in English. It is understood that we will only reach this situation when any application uses the same building blocks for language support. Once these building blocks are defined in standards, libraries and code generators can implement them making them available to any developer for any application.

There are still plenty of challenges ahead of us.
Thanks,
      GerardM

Digitizing a #Malayalam #dictionary

Digitizing a Malayalam book is quite different from digitizing an English book. For an English book you use OCR and move straight on to the proofreading and formatting of the text.

It becomes even more interesting when the text is rich in all kinds of annotations like in this dictionary. It is the the first Malayalam-English-Malayalam Dictionary by Dr Herman Gundert. There are all kinds of opportunities here, ehm problems.

There is no OCR for Malayalam yet so it has to be crowd sourced. The annotations are cryptic and make only sense in a dead tree dictionary. When you digitize such a text and it remains a flat text and consequently it is extremely hard to use the public domain content elsewhere; in OmegaWiki or in Wiktionary for instance.

Santhosh is experimenting with Semantic MediaWiki . It will allow for exportable information and, that will make the data gained much more useful.
Thanks,
       GerardM

To #twitter in "indigenous" languages II

At this moment #Wikipedia supports many more languages than indigenoustweets.com. I can imagine that having tweets in our languages is something that is of interest to our language communities.

S07E29c from Brian Lehrer Live on Vimeo.

Kevin Scannell in this interview with Brian Lehrer is quite clear: he is interested in every small language. It might be an idea to link to Indigenoustweets on project like OmegaWiki and translatewiki.net where portals can be found for many languages.
Thanks,
        GerardM

What to do when the #CLDR does not have it

At #translatewiki.net we use standards. It makes our life a lot easier because it prevents us from arguing about things we do not really know about. When there is a standard, we have always referred to the standard and asked people to update the data in the standard.

The CLDR is a standard where you can enter the name of languages and currencies and time formats... A long list of items is supported. One problem is that the CLDR supports 217 languages. At translatewiki.net we support 344 languages. When our people experience problems with getting data into the CLDR, at some stage we want to reconsider.

As we may be getting into the collection of translations for things like the names of languages, we will do this reluctantly and we will continue to give precedence to the information provided by the standards. Another thing is that there are many lists with the translations of language names and it does not makes sense to do the same thing yet again. One such can be found at OmegaWiki...

Another reason to be reluctant is that working on such functionality keeps our developers from more hard core work needed at translatewiki.net. We are very much like any open source project; there are more then enough ambitions and we welcome all the help we can get.
Thanks,
       GerardM

Is this really how you understand language issues?

When people of the #Wikimedia Foundation write about language issues, it is most often a disappointment. When it is suggested that the list is ordered by the ISO-639-1, there is no place in the list for the many many languages that have no such code. There are only 162 languages with such a code and, we have many more Wikipedias. Cherokee for instance has the code chr and French is ᎠᎦᎸᏥ in Cherokee.

not properly sorted.

When a list of languages is shown in the way it is written in that language, the ones in Latin characters come first. When people cannot recognise that languages are written in their native script, it makes sense to provide them with a pointer. This would help a Hindi speaker to type हिंदी.

do you spot two font issues..

When such a list is to be completely in the local language as suggested, it would create several problems. Many people like me have a user on many Wikipedias, the language setting is sadly not a global feature and with the word Nederlands no longer available, the usability is destroyed for me and a large group of people. The second problem is to complete a list of the names of languages for all the Wikimedia languages. OmegaWiki has many of them readily available.. Thirdly many Wikipedias are not in one script or orthography. The text of articles on the Serbian Wikipedia for instance are available both in the Cyrillic and the Latin script. Finally most Wikipedians have insufficient or incomplete support for the fonts required.

The suggestion of a "universal language picker" assumes that language names are uniquely identified in that way. This is just not true. The assumption is also that there is a need for a language picker on Commons. The language should be based on the language of the user interface the only possible reason why this would not work is when Commons decides to allow for anonymous uploads.

We are asked for an opinion and having a language picker makes sense in the user preferences. Allowing for a global default would be a huge usability improvement. When it is also possible to override them locally, it would be bliss.
Thanks,
        GerardM

Representing numbers in #Wikipedia

In a discussion on IRC the representation of numbers was discussed. It turns out that numbers are not really considered in MediaWiki. When you want to express a number it is expected that you use Arabic numerals.

When other numerals are in use for a language, the trick is to change the CSS to replace the characters. The problem is how to turn this off for the article on numerals..

OmegaWiki has a nice way of annotating the different expressions for a number.. It is defined on the number class. The only thing left is learning in how many ways a number like two can be expressed.
Thanks,
      GerardM

#OmegaWiki is back online

When a technician does not know that a live application is running on a server, he will just turn the server off. That is what happened to OmegaWiki two weeks ago.

What happened next was an amazing group of people getting together, they found someone in the USA willing to go to the office where the server was, take it home and in a multi-continent operation get the data from that system.

OmegaWiki is now operational again; it runs on a server of Erik Moeller, Siebrand, Kim and Marc worked on the issue from the Netherlands and Cyde in the USA. Once the server was up and running, it was Kipcool who got everything working again.

I am really grateful for the hosting we received in the past from Knewco, I am really grateful and happy for the support of so many fine men who brought this project that has so much passion, love, work in it back from the brink.
Thanks,
      GerardM

The Queen of Hearts

The Wikivoices episode that is to be recorded today, will be writing an article about some famous children's rhymes. One of them is the "Queen of Hearts". The idea is that a new Wikipedia article will be created and will be brought to a level where it is a DYK.

I was asked to join and ... well not only is the text new to me but also the words are foreign to me. Words that are a bit archaic would be my excuse.. I pride myself for my English so I found my role.. I will add all the words that I do not know or that I am uncertain off to OmegaWiki.
Thanks,
      GerardM

PS the recording will start in 40 minutes...

A plugin for aditional support

I have added the "Linker button" to my blog. It allows you to discover more about some of the concepts that are used on my blog. In the screen shot you see information about publications for the concept "handwriting".

The terminology used is based on what can be found in Wikiprofessional.org. This contains a really rich resource for biomedical terminology. It includes information like publications and authors from Pubmed (for the security conscious among you, Pubmed is seen here through the "Conceptweblinker").

The cool thing for me is that Wikiprofessional in its wiki part is based on the OmegaWiki mark I technology. We are currently working hard on making the data mining engine mindful of new concepts that are entered in the Wiki. When we have this working, I can make sure that all the concepts in my blog are known to the engine and in this way my blog becomes easier to understand for those whose English is not as good as mine.

The current terminology is quite extended. From the Conceptweblinker and from Wikimore.org you can experience what can already be done for the English language Wikipedia. Given the terminology, it works best for those articles that are in the bio-medical domain.

When you are interested in having this feature enabled on your website or blog, just put this code snippet in the right place..

<script type="text/javascript" src="http://conceptweblinker.wikiprofessional.org/wikibutton.js"></script>

There is even a plugin for Firefox only at the moment...
Thanks,
GerardM

Digg drugs

I found this article on Digg, as you can see it is highly rated and, it seems to have its origin on en.wikipedia.

 

When you actually go to the article, the image is on Commons. It is the type of picture that paints a thousand words. Even better, it is in SVG, and there is a  Toolserver tool that helps you to translate the text in your languages. This was easier said then done because the word "Dependence" has fewer characters then "Afhankelijkheid". 

I installed Inkscape because the tools that I have on my computer did not work well for me. What I learned is that this is because of the orientation of the characters. With another orientation, the Toolserver tool would have had no problem. 

When you look at the labels in the text, you may agree with me that what is needed is mainly the translation in another language, something that should be possible from a dictionary resource like Wiktionary or OmegaWiki. OmegaWiki does have the ability to be queried. This opens up the possibility to show all the words in the language selected in the user preferences or the language of the page when the translations are available.
Thanks,
        GerardM

Wikimedia meet Brussels

For the second time, a call went out on the Dutch Wikipedia; there will be a Wiki meet up in Brussels. WalterBE had been contacted that SJ would be in town and this was enough of a reason for a meeting. It is the second time that there was such a meet up; the first time in the day when Wikipedia was young, there was much more advance warning and, in the end there were two people. Walter and myself. We had a good time; went to what was the colonial museum and ended up in Gent where we saw this beautiful city by boat. The 2008 meeting featured a 50% increase of attendees counting the Dutch language Wikipedians.

This time it was OLPC time. Samuel was in Europe for a meet-up of key OLPC Europeans, they were there to smoothen the roll out of their “get one, give one” project. Meeting these people is quite similar to meeting Wiki people, there is a similar spirit of enthusiasm and passion. They are knowledgeable and there is a perceivable spirit of “we are going to make this work”.

I had reasons to be amazed. When people ask me about the projects that I am involved in, I always mention SignWriting. It is not that I consider myself the most knowledgeable or the best placed person to promote this wonderful cause, I do promote it and this has become a cause that is dear to me. I was amazed that one of the people there actually knew about it; he had learned about it at Gallaudet university and he even expressed an interest in testing the latest software on the XO.

Many of the issues that I have noticed with MediaWiki are as relevant for the OLPC. Usability, localisation and managing a complex infra structure are key. What I am grateful off is that with the OmegaWiki mark II approach it may have a chance to get a similar relevance for other platforms like the OLPC.

Thanks,
GerardM

In need of more glue

Wikipedia is about encyclopaedic content. Articles about the same concept are connected by "InterWiki" links. Links may exist to the Wiktionary in the same language for lexical information and when there are many files in Commons, there may be a link to Commons as well. These connections are the glue that bind the projects, and the languages together. They add real value to the projects. This value is already recognised in the way the search engine now provides links to sister projects in the same language.

The links between projects are extremely valuable. Some are inferred as in the search engine and some are made explicit as in the InterWiki links. When you read an article in a language where the article is only a stub, you can find more information through the interwiki links.

Everything should be linked in order to provide the best information and to make life easier for our readers, we should not forget the projects with little or no content. For them there is no place to make these connections. For these languages the least amount of information is not available anyway therefore the challenge is to provide a place where they can start connecting information for their people.

OmegaWiki starts with a concept. This concept is defined in a language and on average nine tranlsations are known for it. When a language is added, slowly but surely a web of connected starts to build. Links to Commons, links to Wikipedia articles in other languages and links to other concepts in OmegaWiki.


When the Wikimedia Foundation has sufficient resources, it may consider to support the not supported languages in this way. OmegaWiki proves that its concept works.



Thanks,
GerardM