RE: altLabels in different langauges

Hello all,
 
> Food for thought...

Ouch ;-)

> My current favourite solution to this problem is to go back to the
> idea of modelling types of note as classes. A single property (e.g.
> "skos:annotation") then links concepts to notes, and another single
> property (e.g. "skos:annotatesLiteral") can link a note to literals
> that are labels for some concept. E.g. ...
> 

Isn't that transferring to the annotations the complexity the
"Terms-as-classes" solution was blamed for?

> I also would favour dropping the use of rdf:value, and have different
> properties for alternate media type values of the annotation content,
> e.g. "skos:noteContentText" "skos:noteContentXHTML"
> "skos:noteContentMathML" "skos:noteContentSSML" etc.

[Just a trivial note: in that case, don't forget to create an umbrella
property like  for skos:noteContent for all these things, that might be
useful to attach new media notes]

> This framework is then flexible enough to allow extension by
> refinement to achieve the translation and abbreviation requirements.
> E.g. a third party could declare ...
>  
> eg:C a skos:Concept;
>    skos:prefLabel "peace"@en, "rust"@nl.
>    skos:altLabel "repose"@en, "serenity"@en, "rusten"@nl,
"sereniteit"@nl;
>    skos:annotation [
>      a x:TranslationNote;
>      x:translationSource "repose"@en;
>      x:translationTarget "rusten"@nl;
>    ];
>    skos:annotation [
>      a x:TranslationNote;
>      x:translationSource "serenity"@en;
>      x:translationTarget "sereniteit"@nl;
>    ].
> 

I see 2 possible problems:
- one obvious is the complexity of the thing for the humans involved in
the loop. Of course we always claim that this is not the core of
semantic web concerns, but a model which is cognitively inadequate will
be difficult to adopt.
- then you might have problems in creating proper the data and using it
in reasoning engines. What if you want state that your translation is
symmetric (if X has Y as a translation, Y has X as a translation)? You
cannot do it with OWL, so you would have to create all links explicitly
when the model is created. Similar problems could happen if you want to
create transitive 'links' between your terms (perhaps not valid for
translation in general, but this situation might happen somewhere else).
Of course you can wait for generic rule languages to be implemented and
adopted, but the solution with OWL properties between terms as instances
would be so easier...

Notice that the solution you propose for this translation process is
actually very similar to statement reification mechanisms in RDF. And
these can be useful, but are not often used in practice, perhaps because
of these complexity issues.

OK, that was for the criticism. But one has to acknowledge that it is
sure that this solution *can* represent the information, without
changing SKOS Core as it is now. Sigh...

Cheers,

Antoine

Received on Wednesday, 31 May 2006 13:40:17 UTC