[Nepomuk] Fwd: sequences

Sebastian Trüg trueg at kde.org
Thu Sep 23 14:25:11 CEST 2010


On 09/21/2010 06:05 PM, Bèrto ëd Sèra wrote:
>     Hi Roman,
> 
>     > /* A "Region" has a textual  description, along with other minor
>     properties,
>     > so we want it to inherit all translation capabilities from Profile */
>     > foo:Region rdf:type rdfs: Class.
>     > foo:Region rdfs:subClassOf foo:Profile .
> 
>     > /* This is where actual content is */
>     > foo:Content rdf:type rdfs:Class .
> 
>     > foo:means rdf:type rdf:Property .
>     > foo:means rdfs:domain foo:Content .
>     > foo:means rdfs:range foo:Profile .
>     ...
>     > foo:belongsTo rdf:type rdf:Property .
>     > foo:belongsTo rdfs:domain foo:Content .
>     > foo:belongsTo rdfs:range foo:Region .
> 
>     Since Region is subclasss of Profile, foo:means property may relate
>     Content to Region.
>      foo:belongsTo seems to serve the same purpose here, or those 2
>     properties should have different semantics?
> 
> 
> It's two different things. Anything that has to appear to a user as
> "language dependent content" (i.e., it'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.
> 
> 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 "system name" generated as
> simply the profile uuid, then we "emerge it as a linguistic dependent
> content" according to his desktop settings. Once emerged, profile
> 1aa75482-4e61-11de-a0cb-e7dd9793c483, tagged as
> 1aa75482-4e67-11de-a0cb-e7dd9793c483 will appear as "dog" tagged as
> "animal", or "cane" tagged as "animale", depending on the user's settings.
> 
> 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'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. 
> 
> The "entries" 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'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' work.
> 
> Getting back to our "region" this is really going to be stuff like
> "en.wiktionary.org <http://en.wiktionary.org>", "de.wiktionary.org
> <http://de.wiktionary.org>", "AGROVOC", "community X" etc. In most cases
> the name is hardly going to be translated at all, as it's a sort of
> trademark, but the definition needs to be, so that a Russian user who
> knows nothing of, say, AGROVOC may read "AGROVOC - это многоязычный,
> структурированный словарь, который охватывает терминологию всех отраслей
> сельского хозяйства, лесного и рыбного хозяйства, пищевой и смежных
> областей (например, окружающая среда).". So he can see it in his list of
> possible "sources" and decide whether such source is of any interest for
> him.
> 
> "Profile" simply means "this thing can be translated and explained as in
> a dictionary" and it's pretty much our base "object". 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's a bit complex, but it gets simpler if
> you make a basic division between "language independent" and "language
> dependent" content.
> 
> 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 "profile" base level.

Explain again please why you can't just use plain literal properties
with different translations?

Cheers,
Sebastian


More information about the Nepomuk mailing list