RE : Example of coordination with DDC

Hello,

> To model the components of a synthesized class, I 
> have been using dcterms:hasPart and when I have needed to maintain the 
> order, use an rdf:Seq.  For example:
> 
> <dcterms:hasPart rdf:resource=Uri"/>
> <dcterms:hasPart rdf:resource=Uri"/>
> 
> or
> 
> <dcterms:hasPart>
>  <rdf:Seq>
>   <rdf:li rdf:resource="Uri"/>
>   <rdf:li rdf:resource="Uri"/>
>  </rdf:Seq>
> </dcterms:hasPart>

I agree that this can be a smart solution, Andrew, but I feel really uncomfortable with it for two first reasons:
- my first understanding of dc:hasPart is really attached to the notion of document inclusion, ie a part-of relationship which is more 'essential' to the entity which plays the role of the part than it is for the one which plays the role of a qualifier (or second component of compound subject) in our coordination case. dc: hasPart can cope with such understandings (after all an image is not 'essentially' part of an HTML page) but SKOS should be careful with that
- then, how do you implement some semantic properties implied by qualification/coordination for information retrival? Imagine that we have 'animal -- running'. If I want to get documents indexed by this compound when querying for 'animal' or 'running' then your system needs to turn to some rule which would be valid for dc:hasPart only when this relation concerns subjects. 

Of course your solution has strong arguments in favor, and it might be perfect for your case. But I would like to hear from you on these specific problems, with your experience.
For me, creating a SKOS property for qualification/coordination (even if we remain at a very general level, e.g. not taking into account all the different relationships of colon classification) would clarfify the situation. It has also the clear advantage of expliciting things: I don't like treating all the subjects on a same level (which is the case of the rdf:seq solution) when they are not (some qualification mechanisms involve terms that are only meant for qualification, and not indexing, so different from the skos:subject they qualify)

> For DDC numbers I use <skos:prefLabel xml:lang="art"> so
> I don't need a new "notation" element. What's you opinion about encoding
> notations and headings in SKOS?

We are currently working on the representation of a nice classification scheme (www.iconclass.nl, by the way we have qualifiers of qualifiers if people are interested ;-) and will test this solution. I have to admit that I find it elegant, even though it seems to me that this 'alt' language value somehow make the implicit assumption that there is one unique artificial language, as there is one English or German one (at least in XML convetions ;-) ) and I'm not sure how a system should behave while being confronted to concepts coming from concept schemes with different notation systems at a same time.

Cheers,

Antoine