W3C home > Mailing lists > Public > public-swd-wg@w3.org > May 2007

Re: ISSUE-26: SimpleExtension proposal

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 29 May 2007 19:41:44 +0200
Message-ID: <465C65D8.3040804@few.vu.nl>
To: Guus Schreiber <schreiber@cs.vu.nl>
CC: SWD WG <public-swd-wg@w3.org>

Hi Guus,

After some answers to Daniel, my own comments...
>
> ACTION: Guus revise his ISSUE-26 proposal to account for other options 
> [recorded in http://www.w3.org/2007/04/24-swd-minutes.html#action07]
> All,
>
> Below is my SimpleExtension proposal for isue 26 (relations between 
> labels). I haven't had time to check the syntax of the examples or put 
> it on the Wiki.
> Guus
Just a question: does your proposal correspond to the third proposal I 
was mentioning in 
http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels ?
>
>
> SKOS ISSUE-26 Relations between Labels: "SimpleExtension" Proposal
>
> This is a proposal for resolution of SKOS ISSUE-33.
>
>
> 1. Vocabulary
>
> The proposal introduces the following new vocabulary:
>
>  skos:Term
>
>  skos:prefTerm
>  skos:altTerm
>  skos:hiddenTerm
>
>  skos:relatedTerm
I think this relatedTerm is too close a name, compared to 
"skos:related", which applies to skos:Concept. And it also confuse to 
the RT (related term) used in thesaurus world, which will be generally 
interpreted as skos:related

Perhaps skos:labelRelation (similar to what was done for 
skos:semanticRelation) or skos:termRelation would be better

Which leads me to another problem, that I had not anticipated when 
previously discussed about this issue. What we want to call "terms" are 
actually what people will call "terms", but also simple "strings" (cf. 
http://lists.w3.org/Archives/Public/public-swd-wg/2007Apr/0011.html). 
I'm afraid "Term" will collide too much with some thesaurus or 
terminology uses, which is less the case for "label".
Does anyone on this list also think this is an important problem? Could 
anyone coin a better name for "term" than the horrible "LabelResource" 
my feeble mind can only imagine for now?
>
>
> 3. Semantic Conditions
>
> * A skos:Concept has at most one skos:pretTerm relation
>
>    skos:prefTerm rdf:type owl:FunctionalProperty.
>
> * A skos:Concept must be the subject of at least one one 
> skos:prefLabel or
>  skos:prefTerm triple.
>    NOTE: there seems to be no reason to forbid mixing of label and
>    class approach. So the "or"is not an exclusive or.
>
> 4. Consistent Examples
>
> EXAMPLE 1
>
> The example below shows two terms for a concept, where one term is 
> defined
> as the acronym of the other term.
>  ex:who    rdf:type skos:Concept;
>    skos:prefTerm ex:who1.
>    skos:altTerm ex:wh02
>  ex:who1    rdf:type skos:Term;
>    rdfs:label "World Health Organization"@en-us;
>    rdfs:label "Wereldgezondheidsorganisatie"@nl.
>  ex:who2    rdf:type skos:Term;
>    rdfs:label "WHO"@en.
>  
>  ex:acronymOf    rdf:type rdf:Property;
>    rdf:subPropertyOf skos:relatedTerm.
>  
>  ex:who2 ex:acronymOf who1.
I disagree here with the practice this example implies. To me, an 
instance of Term should have only one rdfs:label (and this should be put 
in the semantic conditions).
In your example, who1 is an acronym of who2. But if "WHO" is an acronym 
of "World Health Organization" it is not an acronym of 
"Wereldgezondheidsorganisatie".
I really think this Term class shall only be a means to "reify" (in the 
sense of making one RDF resource out of something which is orginally not 
one) a literal used as a label. And not to introduce something that 
could compete with skos:Concept.
Which makes me think I've got my candidate to replace term: 
"lexicalization". Not very beautiful, but better imho.
>      
> 6. Entailment Rules
>
> DISCUSSION: should we have an entailment rule that says something
> like:
>
>  for every <x>Term statement (where x can be either pref, alt or
>  hidden) tools are allowed to assert a <x>Label triple for each of
>  the rdfs:label statements of the object of the <x>Term statement.
>
> So from example 1, applications derive  the following additional triples:
>
>  ex:who    skos:prefLabel "World Health Organization"@en-us;
>    skos:prefLabel "Wereldgezondheidsorganisatie"@nl;
>    skos:altLabel "WHO"@en.
+1
>
> DISCUSSION: should the inverse also be true? E.g should applications be
> allowed to derive the following:
>  ex:who    skos:prefLabel "World Health Organization"@en-us;
>    skos:prefLabel "Wereldgezondheidsorganisatie"@nl;
>    skos:altLabel "WHO"@en.
>
>  entails
>
>  ex:who
>    skos:prefTerm      [a skos:Term        rdfs:label "World Health 
> Organization"@en-us;
>        rdfs:label "Wereldgezondheidsorganisatie"@nl];
>    skos:altTerm      [a skos:Term        rdfs:label "WHO"@en].
+1
>
> NOTE: the difference with example 1 is here that the instances of
> skos:term are represented as blank nodes.
In 4 the example might have used a blank node as well, I think, making 
it similar to your 'generated' information.

>
> 8. Discussion
>
> The objective of this proposal is allow term relations, while
> preserving compatibility with the label approach.
> The main alternative would be to drop the semantic constraint on the
> <x>Label properties to be an owl:DatatypeProperty. This would make the
> following example consistent:
>
>  ex:who    rdf:type skos:Concept;
>    skos:prefLabel ex:who1.
>  ex:who1    rdf:type skos:Term;
>    rdfs:label "World Health Organization"@en-us.
>
> even in combination with:
>
>  ex:who    skos:prefLabel "World Health Organization"@en-us;
>
> One can view this of the MinimalFix proposal but has two
> disadvantages: - ambiguity wrt the range of the skos:<x>Label properties
> - incompatibility with OWL DL, as it is not possible to define the
> label properties as either an objector a datatype property.
> The SimpleExtension proposal preserves OWL DL compatibility.
> The entailment rules mentioned under 6 are meant to preserve
> interoperability between vocabularies that use different approaches to
> represent lexical labels.
Notice that although I like your new proposal. This 'loosening' of 
pref/alt/hiddenLabel is clearly my preferred one, even if we lose OWL-DL 
compatibility.

Cheers,

Antoine
Received on Tuesday, 29 May 2007 17:41:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:49 UTC