Pete,

I'm still waiting for the day when the penny drops in my brain and I
comprehend the whole "value is a resource, etc." thang intuitively
(still waiting after two years...sigh).  However, I'm usually looking at
these things from the implementation p.o.v...

I understand your set of three triples - that XYZ (a collection) has a
thumbnail relationship with http://.../image/333 (a DCMIType=Image), but
what if the object in the thumbnail relationship is not a URL but an
embedded bitstream?  It still has a type of Image, but I really need to
know whether I should be looking in it for a URI scheme plus colon or
extracting the whle thing as a bitstream.  DC CD AP doesn't require
cld:logo to be a URI/URL so I should be able to embed a bitstream in my
implementation of the AP (not that I'm saying I necessarily will)?

I'm not quite sure of the extra triple you would add to indicate this
(if indeed it is possible)?  This is why I used the XLink stuff to allow
for richer specification of the link, though I realise I may have erred
slightly - I was sure it validated as RDF OK when I dreamed it up last
year, though possibly it's only valid at a syntax level rather than at a
semantic level??

Douglas

>>> [log in to unmask] 16/09/04 06:32:52 >>>
> 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.

Yes. To be honest, I don't really want to get sidetracked into this
discussion here. I think we recognise that the current recommendation
for encoding DC in XML [1] is flawed/under-specified in this area and
something needs to be done about it. And we will make some proposals
to
try to address that.

FWIW, I think we should try to avoid using xsi:type in discussion of
examples here, because (IMHO) it is not sufficiently clear what
information - in terms of the DC grammatical principles and/or the
DCMI
Abstract Model - we are providing when we use it (other than - as
defined by XML Schema - an XML Qualified Name which is the name of an
XML Schema datatype).

So below I resort to N-Triples [2].

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

And that information is provided by supplying an explicit type for
that
resource by saying

<http://example.org/image333> <http://purl.org/dc/elements/1.1/type>
<http://purl.org/dc/dcmitype/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.

OK, but I don't think how the software gets the image is covered by
the
DC CD AP. I think we need to make a distinction between identification
and dereferencing or interaction.

The three statements:

<http://example.org/collection/XYZ>
<http://example.org/terms/thumbnail>
<http://example.org/image/333> .

<http://example.org/collection/XYZ>
<http://purl.org/dc/elements/1.1/type>
<http://purl.org/dc/dcmitype/Collection> .

<http://example.org/image/333> <http://purl.org/dc/elements/1.1/type>
<http://purl.org/dc/dcmitype/Image> .

say that there is a relationship between the subject resource (
http://example.org/collection/XYZ ) and the object resource (
http://example.org/image/333 ) and the nature of that relationship is
represented by the property http://example.org/terms/thumbnail

All three of these URIrefs are identifiers: by using these identifiers
in this statement, I am saying nothing about what behaviour I might
expect if I dereference any of those identifiers or what mechanism I
should use to dereference them. I think that behaviour and/or the
dereferencing mechanism might vary depending on my context, but the
use
of the URIrefs as identifiers is context-independent.

> 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 can see that this may be useful information for your application,
but
I am not quite sure that it should be provided by what DCMI calls a
vocabulary encoding scheme (which describes the type of a non-literal
resource) or a syntax encoding scheme (which describes the type of a
literal). Doesn't an application obtain this information by inspecting
the URI itself, especially the URI scheme?

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

Well, as I said above, I'm not convinced that we (Andy and I!) are
really sufficiently clear about what information we are providing when
we use the xsi:type attribute as described in [1]

Pete

[1] http://dublincore.org/documents/dc-xml-guidelines/
[2] http://www.w3.org/TR/rdf-testcases/#ntriples