-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Theo van Veen
Sent: Wednesday, September 15, 2004 4:26 PM
To: [log in to unmask]
Subject: Re: Betr.: Re: Do we need a separate property for logo?

On 15 Sep 2004 at 19:32, Pete Johnston wrote:

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

OK.

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

I realise that my problem partly has to do with the distinction of URL as
location and URI as identifier.
In TEL we make a distinction between xsi:type=dcterms:URI and
xsi:type=tel:URL.

>
> > 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 don't know. In many cases a scheme is not needed because the application
profile
offers sufficient information. I would expect that inspecting the the URI of
a property (if
that is what you mean) is done by the implementor on beforehand to present a
certain
property in an application and not by the application afterwards.But I agree
that when
both types of encoding schemes are explicitly available that applications
might deal
with obtained metadata in a more flexible and intelligent way.


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


Theo