Re: [PORT] SKOS Core 2nd Review: symbolicLabelsRange-3

Miles, AJ (Alistair) wrote:

>Hi Ralph,
>
>  
>
>>--
>>[11]symbolicLabelsRange-3
>>  refactor symbolic labelling properties and change range
>>  to DCMI type Image.
>>
>>The semantics of altSymbol and prefSymbol feel under-specified to me.
>>I cannot, for example, decide whether the use case would be adequately
>>(or perhaps better) handled through additional to UNICODE such that
>>the desired symbol(s) can be conveyed as text.  It is not clear
>>whether symbols used as "preferred symbolic labels" should have
>>glyph-like semantics.  The BLISS example and reference would
>>support such a presumption.  I suggest there exists here an
>>opportunity to add clarity.
>>    
>>
>
>What do you mean by 'glyph-like semantics'?
>
>The original idea was just to allow folks to 'label' their concepts with images (that have GET-able representations as jpeg/gif/png/svg/blah), where the image depicts a symbolic representation of the concept, for the purpose of creating graphical representations in web documents etc.  
>
>Do you have any suggestions for how we can add clarity?
>
>  
>
>>I appreciate the utility of moving the grounding from FOAF to DCMI
>>but the comment that raised this issue noted that there were other
>>FOAF dependencies.  I wonder why the remaining one (subjectIndicator)
>>is not being addressed?
>>    
>>
>
>To be honest, I'd forgotten that the range of skos:subjectIndicator is foaf:Document.  I'd be happy to discuss this for the next review.
>  
>
I wish TAG would define a class 'information resource'. Document is such 
a slippery concept. But then, so is 'information resource'. I don't 
think FOAF's treatment of Document is likely to change, until such time 
as FRBR-ish concepts (work vs expression vs manifestation vs item) get 
some compelling expression in RDF. At which time we'll probably move to 
using that instead. Not holding my breath.


>  
>
>>Any objection based on the semantics of DCMI:Image are apparently
>>made moot by the stated intention [12] to modify the FOAF
>>specification.  Clearly, if FOAF:Image becomes a subclass of
>>DCMI:Image the net result is the same for applications.
>>    
>>
>
>I don't think this is true.  Just because FOAF has made the foaf:Image class a sub-class of dcmitype:Image, what guarantees do I have as an implementer that this won't change?  
>
>I can understand implementers currently preferring a dependency on DCMI, where all changes however minor have to go through the Usage Board and public comment periods, to a dependency on FOAF, where the reality is that Danbri can and does tweak on short notice.  
>  
>
I generally agree, although there have been discussions in the DC world 
about making radical changes in the RDFS for the main DC properties, 
beyond anything I'd dream of doing for FOAF. We're all making up best 
practices here as we go along... trying to understand the costs, risks 
etc of changing in place versus of migrating to new namespaces. That 
said, FOAF is generally more of a 'here be dragons!' testbed than DC, 
and yes, it doesn't have a Usage Board, beyond informal interactions 
with the email and IRC community around it.

Dan

Received on Friday, 7 October 2005 16:15:45 UTC