Re: ISSUE-180: Last Call Comment: PFWG: skosxl:Label class

Hi,

I am rather against releasing the restriction on skosxl:literalForm. We 
introduced it as a means to have annotations on labels, and links at the 
level of labels, but not to introduce a new level of labelling (that is, 
non string-based, for instance).
Indeed we're try to have these "enhanced" labels as related as possible 
to the plain literals that are used as objects of skos:prefLabel. Hence 
the axioms S55, S56 and S57 (in the July 30 editor's draft [1]). They 
"dumb-down" the XL labels, but also help ensuring that what is done with 
the SKOS-XL extension does not go against the design and semantics of 
standard literal labelling properties.

Further, I think your solution (1) will already catch a number of use 
cases without opening that can of worms. If the accessibility-related 
use case complies with the philosophy of standard SKOS labelling, then 
it is perfectly feasible to use accessibility-related properties with 
instances of skosxl:Label, in addition to the literal form of these. 
Your analogy with the text captions given to HTML image is I think 
especially appropriate as the way to proceed then.

If we allow for your (2) approach, then it means that XL more-or-less 
allows enables labels on which we have no real control from a data model 
perspective. And maybe it's a bit again what we decided for ISSUE-76 [2]...

By the way where is in the Reference the axiom that says that an 
instance of xl:Label should have exactly one literal form? I can find in 
A.2.4.1 a sentence that says
> As stated above, each instance of the class xl:Label has one and only 
> one literal form

But the only formal axiom that may correspond to that is the one that 
states that literalForm is an owl:FunctionalProperty...

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/SKOS/reference/20080730/
[2] http://www.w3.org/2006/07/SWD/track/issues/76
> The second part of this comment needs some discussion before I can
> frame a response...
>
> Executive summary:
>
> It would be a good thing if the SKOS XL vocabulary could serve as an
> extension point for the provision of labels in other modalities, for
> example in accessibility-related use cases.
>
> To serve as an extension point, we have to either
>
> (1) live with the current XL data model, especially the restriction on
> the cardinality of skosxl:literalForm, which requires that all
> instances of skosxl:Label have exactly one plain literal form (even if
> they are intended to convey a label in another modality).
>
> or
>
> (2) relax the restriction on skosxl:literalForm, such that instances
> of skosxl:Label are not required to have a plain literal form (but if
> they do, they have at most 1)
>
> Personally, I think I favour (2), although it requires a substantive
> change to the SKOS Reference.
>
> Further discussion below...
>
> On Wed, Oct 08, 2008 at 09:54:57AM +0000, SWD Issue Tracker wrote:
>   
>> ISSUE-180: Last Call Comment: PFWG: skosxl:Label class
>>
>> http://www.w3.org/2006/07/SWD/track/issues/180
>>
>> Raised by:  Everyone
>> On product: All
>>
>> Raised by Al Gilman on behalf of PFWG in [1]:
>>
>> """
>>     
> [...]
>   
>> The label framework should explicitly cater for non-textual labels in  
>> image, audio or video format, and as provided in other markup  
>> languages such as MathML.  Labels in other modalities may serve as  
>> alternate labels in accessibility-related use cases.  SKOS should  
>> provide guidance as to how to provide images, audio and video content  
>> as alternate labels.  Currently, icons are being standardized as  
>> representing concepts in an upcoming multi-part standard ISO/IEC  
>> 11581, developed by ISO/IEC JTC1 SC35.  SKOS should be able to  
>> specify these icons as part of a knowledge organization system.
>>     
> [...]
>   
>> """
>>     
>
> Currently the SKOS Reference defines skosxl:Label as "a special class
> of lexical entities". It also says that "each instance of this class
> has a single plain literal form...". 
>
> This is reinforced by statement S53, where skosxl:Label is a sub-class
> of a restriction on skosxl:literalForm cardinality exactly 1.
>
> This raises a possible problem for use of the XL vocabulary as an
> extension point for extensions as described by Al above.
>
> For example, let's say a third party wants to extend the SKOS XL
> vocabulary to represent labels in various XML markup languages. They
> define extensions as follows:
>
> ex:XMLLabel rdf:type owl:Class ; 
>   rdfs:subClassOf skosxl:Label .
>
> ex:xmlLiteralForm rdf:type owl:DatatypeProperty ; 
>   rdfs:domain ex:XMLLabel ; 
>   rdfs:range rdfs:XMLLiteral .
>
> ex:xmlContentType rdf:type owl:DatatypeProperty ;
>   rdfs:domain ex:XMLLabel .
>
> to be used as in e.g.
>
> <MyConcept> skosxl:prefLabel <MyXMLLabel> .
>
> <MyXMLLabel> rdf:type ex:XMLLabel ;
>   ex:xmlLiteralForm """E = mc<sup>2</sup>""" ;
>   ex:xmlContentType "application/xhtml+xml" .
>
> The potential problem is that the XL data model currently requires
> that *every* instance of xl:Label has a plain literal form. Therefore,
> the example above entails
>
> <MyXMLLabel> skosxl:literalForm _:aaa .
>
> where _:aaa is some as yet unknown plain literal.
>
> In practical terms, this means that every refinement of the
> skosxl:Label class should always give a plain literal form for the
> label, in addition to whatever other modality is the primary carrier
> of the label.
>
> >From an accessibility point of view this is not necessarily a bad
> thing. I.e. it's very roughly analogous to requiring alt text for
> images in HTML. However it is a bit restrictive for all cases.
>
> The alternative would be to relax the definition of the xl:Label
> class. So instead of
>
> """ A special class of lexical entities, called skosxl:Label, is
> defined. Each instance of this class has a single RDF plain literal
> form, but two instances of this class are not necessarily the same
> individual if they share the same literal form. """
>
> we say something like
>
> """ This appendix defines a class called skosxl:Label. Each instance
> of this class has at most one RDF plain literal form, but two
> instances of this class are not necessarily the same individual if
> they share the same literal form. """
>
> and we replace S53 with either
>
> """
> skosxl:Label is a sub-class of a restriction on skosxl:literalForm cardinality at most 1.
> """
>
> or (reverting to the previous model)
>
> """
> skosxl:literalForm is an instance of owl:FunctionalProperty.
> """
>
> What do you think?
>
> Cheers,
>
> Alistair.
>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0063.html
>  
>

Received on Friday, 24 October 2008 08:29:02 UTC