<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Hi!</div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0,8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="im">> In these terms you can think of an entire system of annotations as uuids<br>> used to tag other uuids. The way you tag them (and what you use to tag<br>> them) makes the most of the ontology, while actual content always steps<br>
> in at "profile" base level.<br><br></div>Explain again please why you can't just use plain literal properties<br>with different translations?<br></blockquote><div> </div><div>Because we don't always have them. A few use cases we need to cover:</div>
<div>1) two sources map the same profile: <a href="http://de.wiktionary.org/wiki/cat">http://de.wiktionary.org/wiki/cat</a> and <a href="http://en.wiktionary.org/wiki/cat">http://en.wiktionary.org/wiki/cat</a> a user may have linked just one of them, and it can be much more than two "regions", so we never know where we "emerge" the profile from. These are NOT translations, as oftentimes none of the sources checked the others for consistency. They are "alternate versions", they are equivalent, since they are grouped by the same profile, but never fully interchangeable;</div>
<div>2) some entries are not textual at all. I can have this: <a href="http://commons.wikimedia.org/wiki/File:Mona_Lisa.jpg">http://commons.wikimedia.org/wiki/File:Mona_Lisa.jpg</a> as an expression, and a textual description for it, or maybe a video in sign language. Again, this may vary very heavily, depending on what "regions" and languages a user links.</div>
<div>3) some entries are too long, say we have a full text from here: <a href="http://www.gutenberg.org/ebooks/2199">http://www.gutenberg.org/ebooks/2199</a> and break it in an ordered sequence. For ancient texts we often have different versions, based on different manuscripts. All of them are legal, none of them is fully interchangeable.</div>
<div><br></div><div>Since we have all of this polymorphism, we decided to implement full polymorphism bottom up. If the properties names were to escape this mechanism, they would need a separate translation process, and we are well aware that the number of volunteers is extremely scarce. Especially since the minimal requirement is a high degree of bilingualism. So if we base our localisation on work that is ready avalilable, we manage to gain an immediate usability.</div>
<div><br></div><div>We DO have translations, however, but "translation" is the result of a traceable process. It's made in community regions, it has an authorship attribution and a Quality Assessment by the admin of the region. These are proper translations, as they are made by identifiable authors based on identifiable sources. Everything else is simply the result of a bot believing an internal wikilink between two editions (or similar) or an admin saying "Hey, this two profiles are actually one!". But this is not a translation, it's rather a semantic annotation.</div>
<div><br></div><div>There is a price for this, in the following terms:</div><div>1) We will have to adapt the existing nepomuk monitor in order to make it able to "emerge" tags, otherwise debugging becomes pretty close to reading machine code</div>
<div>2) For small languages there may NOT be a ready equivalent/translation for a given property. This is solved by letting the users choose a fallback strategy, and having a "panic" language (most probably English) to address the case when even the fallback strategy fails.</div>
<div><br></div><div>Bèrto</div>