RE : RE : Example of coordination with DDC

>
>  The described resource includes the referenced resource either physically 
>  or logically.
>
>The definition merely states that the referenced resource must be a physical
>or logical part of the described resource.  That could apply to documents,
>e.g., your example of an image being part of an HTML resource, or the
>components that comprise a skos:Concept.

I agree with your correction. Indeed I had already gone to the DC site to check it, but I was still sceptical, and still am. This 'inclusion' remains to me clearer in the document case than in the concept case. What if somebody wants to say that Dog dc:hasPart Leg? I'm really not an expert in DC, but it seems that the definitions are fuzzy enough to allow it. If you turn to dc:hasPart to represent composition, you'll have either to keep this use restricted to your particular application, or to warn your more general audience that you are associating dc:hasPart with a meaning more precise than the original intended one.

>There is nothing that stops you from applying semantic properties given the
>solution I have been using for Dewey.  If I needed to apply semantic properties,
>then I would just do the following:

><dcterms:hasPart>
>  <rdf:Seq>
>    <rdf:li>
>      <rdf:Description rdf:about="uri">
>        <!-- semantic properties -->
>      </rdf:Description>
>    </rdf:li>
>  </rdf:Seq>
></dcterms:hasPart>

Sorry, here I was really unclear. By 'semantic properties', I was trying to refer to logic axioms valid for your composition (like the one saying that skos:broader is transitive). For example if you want to say that a synthethised class is more specific than the individual classes it is composed of (which might be interesting in information retrieval) you'll have to create in your system some axiom that will be valid for some use of dc:hasPart, but not all (at least not the ones denoting inclusion between documents). Of course that could be feasible, but not really straightforward.


>One has to realize that the focus of SKOS from the beginning was from a
>thesaurus perspective, not a subject heading or classification perspective.

Perhaps it was at the beginning, but now it still reads 
   SKOS Core provides a model for expressing the basic structure and content of concept schemes
   such as thesauri, classification schemes, subject heading lists, taxonomies, 'folksonomies', 
   other types of controlled vocabulary, and also concept schemes embedded in glossaries and terminologies.

>Just having a framework architecture for
>controlled vocabularies is useful and SKOS provides just that.  For things
>like synthesized numbers, which are classification specific, it is not
>inconsistent to use or define other namespaces to fill that need.  SKOS
>already takes this view with its mapping namespace "smap:".

I agree with you on the principle, but it might be that the general 'composition' issue is not specific to synthetised numbers in classifications: subject headings can involve coordination, can't they?

>> > For DDC numbers I use <skos:prefLabel xml:lang="art"> so

>I don't remember writing the above, but if I did it was an oversight.

Don't panic, you didn't write that. But Jakob did, and you let it in your mail so I answered there. 

>From
>the Dewey editors perspective, the preferred label for a DDC concept is the
>class number, not the caption or indexing terms associated with the concept.

Apparently it was a good idea to make you doubt on your words ;-). Jakob was waiting for feedback on his solution, and I find your reminder (and the example) very relevant for the case!

Antoine