>>> [log in to unmask] 14-9-04 20:18:00 >>>

>OK, but regardless of whether we use
>
>- the property dc:description:
>my:collection dc:description my:logo .
>
>- a new sub-property of dc:description
>my:collection dcterms:thumbnail my:logo
>dcterms:thumbnail rdfs:subpropertyOf dc:description
>
>- a new property which is not a sub-property of dc:description
>my:collection dcterms:thumbnail my:logo
>
>in each case we are describing a relationship between a Collection and
a
>second resource, and that second resource is an image. A vocabulary
>encoding scheme by definition describes the type of that second
>resource, so the encoding scheme should be dcmitype:Image, not
>dcterms:URI.

As there seem to be different "types" of encoding schemes and because
properties are considered as resources we need besides xsi:type another
attribute to indicate that the value is a URI.  My question in these
situations is "what information is needed (mostly by software) to deal
with the property?" In order to make a property - in this case a
thumbnail - useful in a meaningful way the software has to _know_
already that a thumbnail is an image. I would suggest to use  xsi:type
when it is needed to correctly use or interprete the value. In this case
of a thumbnail is _defined_ as image in itself, but the software still
needs to know how to get the image.

In the TEL application profile we use <tel:thumbnail
xsi:type="tel:URL"> and <tel:thumbnail xsi:type="tel:URN"> because the
TEL portal needs to know whteher it is a straightforward URL or whether
it should be send a resolution service.
I consider (maybe that is wrong) the xsi:type attribute as specifying
the possible values and their interpretation for those situations in
which it would otherwise be ambiguous.

Theo