RE: RE : Example of coordination with DDC

> From: public-esw-thes-request@w3.org
> Sent: 07 August, 2006 04:48
> To: public-esw-thes@w3.org
> Subject: RE : Example of coordination with DDC
> 
> > 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)

I disagree with dcterms:hasPart being attached to the notion of document
inclusion.  Dublin Core makes no such assumptions as it specifically talks
about resources, not documents.  The definition for dcterms:hasPart is:

  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.

> - then, how do you implement some semantic properties implied by 
> qualification/coordination for information retrival? Imagine that we have 

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>

> 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 

One has to realize that the focus of SKOS from the beginning was from a 
thesaurus perspective, not a subject heading or classification perspective.
As such, I don't expect that it has to accommodate everything that other
controlled vocabularies need.  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:".

> > 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.  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.

For example:

<skos:Concept>
  <skos:prefLabel>700</skos:prefLabel>
  <skos:altLabel xml:lang="de">Künste und Unterhaltung</skos:altLabel>
  <skos:altLabel xml:lang="en">Arts & recreation</skos:altLabel>
  <skos:altLabel xml:lang="es">Artes y recreación</skos:altLabel>
  <skos:altLabel xml:lang="fr">Arts et loisirs</skos:altLabel>
  <skos:altLabel xml:lang="it">Le arti    Belle arti e arti decorative</skos:altLabel>
  <skos:altLabel xml:lang="ru">????????? ? ?????</skos:altLabel>
</skos:Concept>


Andy.

Received on Monday, 7 August 2006 16:49:59 UTC