<meta http-equiv="content-type" content="text/html; charset=utf-8"><div class="gmail_quote"><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">Hi Roman,<br><br>&gt; /* A &quot;Region&quot; has a textual  description, along with other minor properties,<br>&gt; so we want it to inherit all translation capabilities from Profile */<br>&gt; foo:Region rdf:type rdfs: Class.<br>
&gt; foo:Region rdfs:subClassOf foo:Profile .<br><br>&gt; /* This is where actual content is */<br>&gt; foo:Content rdf:type rdfs:Class .<br><br></div><div class="im">&gt; foo:means rdf:type rdf:Property .<br>&gt; foo:means rdfs:domain foo:Content .<br>
&gt; foo:means rdfs:range foo:Profile .<br></div>...<br><div class="im">&gt; foo:belongsTo rdf:type rdf:Property .<br>&gt; foo:belongsTo rdfs:domain foo:Content .<br>&gt; foo:belongsTo rdfs:range foo:Region .<br><br></div>
Since Region is subclasss of Profile, foo:means property may relate<br>Content to Region.<br> foo:belongsTo seems to serve the same purpose here, or those 2<br>properties should have different semantics?<br></blockquote></div>
<br>It&#39;s two different things. Anything that has to appear to a user as &quot;language dependent content&quot; (i.e., it&#39;s expressed in a language) is a subclass of profile. So even a tag name is, as we want to tag something with a Japanese tag サッカー and have it read by a Russian user as tag Футбол, by a German as tag Fußball etc. Nevertheless, a profile is just a dictionary entry, while its subclasses are specialized things that happen to be translatable (as expressions) and explainable/translatable (by means of their their definitions) as anything else. This is really just about being able to manage a multilingual environment.<div>
<br></div><div>Since サッカー is already going to be included in our dictionary sources (basically all words and most common expressions will be, at least for the 10 most common languages), when a user adds a free tag we look for it in the profile list and have the tag &quot;system name&quot; generated as simply the profile uuid, then we &quot;emerge it as a linguistic dependent content&quot; according to his desktop settings. Once emerged, profile 1aa75482-4e61-11de-a0cb-e7dd9793c483, tagged as 1aa75482-4e67-11de-a0cb-e7dd9793c483 will appear as &quot;dog&quot; tagged as &quot;animal&quot;, or &quot;cane&quot; tagged as &quot;animale&quot;, depending on the user&#39;s settings.</div>
<div><br></div><div>This allows an easy semantic data exchange among people who absolutely do NOT understand each other. It also means that less resourced languages get the full wealth of what major languages did as soon as they translate the dictionary. It&#39;s also important for industrial applications. Think of companies that work in different continents and use a semantic network to exchange information about a project, applications are endless. </div>
<div><br></div><div>The &quot;entries&quot; as we said can be either expressions or definitions, and they can either be textual or multimedia. There is no limit to the number of synonyms and alternate or specialized expr/def. So I can have a conference video and its audio in English as a expression, then translate the audio in French. Since we are going to serve HTML5 multimedia, this means we can sync the French audio or superimpose  a Sign Language translation of it (which is technically a video translation of an audio file) at rendering time. Nobody needs to download stuff they don&#39;t understand, unless they specified they want it. Or I can include a literary work from the Gutemberg Project in the expression (as a synonym of the title) and translate it. This is why we need to break long text in shorter ordered sequences, to simplify the translators&#39; work.</div>
<div><br></div><div>Getting back to our &quot;region&quot; this is really going to be stuff like &quot;<a href="http://en.wiktionary.org">en.wiktionary.org</a>&quot;, &quot;<a href="http://de.wiktionary.org">de.wiktionary.org</a>&quot;, &quot;AGROVOC&quot;, &quot;community X&quot; etc. In most cases the name is hardly going to be translated at all, as it&#39;s a sort of trademark, but the definition needs to be, so that a Russian user who knows nothing of, say, AGROVOC may read &quot;AGROVOC - это многоязычный, структурированный словарь, который охватывает терминологию всех отраслей сельского хозяйства, лесного и рыбного хозяйства, пищевой и смежных областей (например, окружающая среда).&quot;. So he can see it in his list of possible &quot;sources&quot; and decide whether such source is of any interest for him.</div>
<div><br></div><div>&quot;Profile&quot; simply means &quot;this thing can be translated and explained as in a dictionary&quot; and it&#39;s pretty much our base &quot;object&quot;. What we derive from it inherits all of its capabilities as a dictionary entry, while having a specialized role (a license, for example, as we also store licensing data, but at the same time care for having a licence text users can understand). I know it&#39;s a bit complex, but it gets simpler if you make a basic division between &quot;language independent&quot; and &quot;language dependent&quot; content.</div>
<div><br></div><div>In these terms you can think of an entire system of annotations as uuids used to tag other uuids. The way you tag them (and what you use to tag them) makes the most of the ontology, while actual content always steps in at &quot;profile&quot; base level.</div>
<div><br></div><div>Bèrto</div>