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