 |
 |
Hi Pete, The clarity is very much appreciated. I don't feel qualified to engage you in too detailed a discussion but - and perhaps naively I understood the challenge with the DC and LOM abstract models in DCAPs to be related to the capacity of the DCAP to provide a basis for a richer and unambiguous semantic to describe and locate a resource. So, if the RDF/A provides a richness of semantic description by enabling the application of various metadata specifications as appropriate to any piece of an XHTML document with an unambiguous Namespace reference to the specification's abstract model expressed in RFD then to what need a DCAP? Thanks again. Cecil E. Somerton Information Management Analyst | Analyste de gestion de l'information IM Strategies | Stratégies de la gestion de l'information Chief Information Officer Branch | Direction du dirigeant principal de l'information Treasury Board of Canada, Secretariat | Secrétariat du Conseil du Trésor du Canada Ottawa, Canada K1A 0R5 613 946-5053 | [log in to unmask] | facsimile/télécopieur 613 946-9342 -----Original Message----- From: DCMI Architecture Group [mailto:[log in to unmask]] On Behalf Of Pete Johnston Sent: Wednesday, June 14, 2006 7:28 PM To: [log in to unmask] Subject: Re: RDF/A and DCAPs Hi Cecil, RDF/A is by definition a specification for representing RDF data. It is based on the assumption that the "terms" being encoded (in XHTML or other XML syntaxes) using RDF/A are "terms" defined/used within the framework of the RDF model. It's a very useful specification, but it does not overcome the problem that DC and LOM "terms" are defined on the basis of different abstract models. RDF/A could be used to represent instance data based on DC-as-mapped-to-the-RDF-model (e.g. as the current DC-RDF draft suggests) and on LOM-as-mapped-to-the-RDF-model - but it still requires that some sort of mapping to a shared abstract model (in this case, the RDF model) is made _before_ the instances can be represented using RDF/A. I don't think RDF/A seeks - on its own - to solve the problems arising from the fact that metadata standards are based on different abstract models, so (IMHO!) I don't think it completely solves the "mixing and matching" problem; rather, it seeks to offer a new way of _representing_ data which is (already) based on a single abstract model (the RDF model). Cheers Pete -----Original Message----- From: DCMI Architecture Group on behalf of Cecil Somerton Sent: Wed 6/14/2006 7:58 PM To: [log in to unmask] Subject: RDF/A and DCAPs Folks, A little off subject I was wondering if there has been any discussion of the implications, if any, for DCAPs in the use of RDF/A. If metadata from diverse specifications can be inserted at different points in an XHTML document then some of the challenges for example of mixing the DC and LOM in a DCAP might be overcome. How the terms used are constrained, encoded, or interpreted for particular purposes could be documented in individual machine readable APs and called from Namespace without conflicts resulting from different abstract models underling the individual metadata specifications. Cecil E. Somerton Information Management Analyst | Analyste de gestion de l'information IM Strategies | Stratégies de la gestion de l'information Chief Information Officer Branch | Direction du dirigeant principal de l'information Treasury Board of Canada, Secretariat | Secrétariat du Conseil du Trésor du Canada Ottawa, Canada K1A 0R5 613 946-5053 | [log in to unmask] | facsimile/télécopieur 613 946-9342 -----Original Message----- From: DCMI Architecture Group [mailto:[log in to unmask]] On Behalf Of Pete Johnston Sent: June 12, 2006 9:01 AM To: [log in to unmask] Subject: Re: Comments on DC-in_XML Hi Ann, > This DC-in-XML document is looking good. A very comprehensive > set of examples. But a few questions and comments: Thanks! > 3.3.1 and 3.4.2 Why does the resource URI and value URI need > to be encoded in full? Is this an XML or a DC restriction? It was/is a "design decision" for the format, not a restriction of the DCAM or of XML. Actually I think Andy and I probably argued over this point ;-) We had an earlier version that had a parallel set of attributes for QNames-mapping-to-URIs for Resource URIs and Value URIs (as well as for VES URIs and SES URIs). I'm inclined to say the current version is rather inconsistent in its approach - _if_ we are allowing QName-mapping-to-URI abbreviations for VES and SES URIs (which of course is open to debate), then I'm tempted to say we should allow them for other URIs in a description too. > I > have XML attribute values that include Qnames which parse > happliy against a schema. > > Examples 5 and 9. I'm a bit dubious about introducing this > use of XML enitities to abbreviate a resource URI. I wonder > if it will just confuse people by introducing this > alternative. Maybe it would be better to just say the URI > must be encoded in full. I also wonder if it is possible to > parse an XML document against its XML schema if it includes a > DOCTYPE, which implies DTD. (This is a question - I meant ot > try it at work last week and ran out of time.) It does require the internal subset to provide the entity declaration, and it requires a parser to process the internal subset, but I think it is OK. I'm fairly sure I tested examples of this using XSV (the W3C XML Schema validator). With Xerces, I think I did encounter a problem with being able to set the appropriate parser flags to get it to read the internal subset without getting upset about the absence of a DTD but, IIRC, that was a limitation of the sample apps that came with Xerces. I think there _are_ some issues around XML Schema validation and entity declarations - I'll check it out, but I _think_ the use of the internal subset is OK. (Also, I'd just note that the DC-XML format can be used independently of XML Schema.) > Example 8 is the same as example 7,even though it illustrates > something different. One could be omitted and reference twice > to save some space. OK. > 3.4.4 Why are there separate attributes vocabEncSchemeURI and > vocabEncSchemeQName? Isn't the nature apparent from the > value? Ah, no, I don't think so. I think if we are going to allow both URIs in full and QNames-as-abbreviations of URIs, an application has to know the datatype of the string in order to process it correctly. I know we human readers are accustomed to looking at strings and deciding whether they are URIs or QNames, but consider the string: name That could be: (a) a relative URI (to be resolved relative to the base URI of the document) (Aside: I'm conscious that we haven't provided any examples of using relative URIs and we probably should do so - or indicate that they are not supported, if the latter is the case) or (b) an XML QName (which would map to an expanded name using the namespace declaration for the default name space - and from that to a URI if the DC-XML format specified that the mapping applied for that QName) And I'm fairly sure (though I can't produce an example off the top of my head!) there are URI schemes which, even if the prefix is present, allow lexical formas which are indistinguishable from the lexical forms of QNames i.e. given a string like ssss:nnnnn how do I know whether that string is a URI and "ssss" is a URI scheme prefix or it is an XML QName and "ssss" is an XML Namespace Prefix? > There is no such distinction in DC-Text. There is ;-) In DC-Text, URIs have to be started and terminated by a "<" and ">"; a string without that is treated as a Qname (if it occurs within a "....URI" construct in DC-Text). > It doesn't seem very elegant. I do think some way of making the distinction is required. However, I would say that supporting both URIs-as-URIs and Qnames-mapping-to-URIs does mean that a parsing/consuming application has to be prepared to support both forms, so using XPath or XQuery over DC-XML gets a bit more complicated - and that does go against one of the design principles we set ourselves. I'm also conscious that there is a broader ebate around this area going on elsewhere e.g. within the W3C group which is looking at encoding DC in XHTML, where they have proposed a new datatype called CURIE http://www.w3.org/TR/2006/WD-xhtml-rdfa-primer-20060310/#id69192 which supports a QName-like abbreviation for URIs - but that is still work in progresss, and a matter of some debate, I think. > Example 15. The same comment as I made to DC-Text. Is an > alternative here to have repeated dc:title properties. Does > this document need to give some guidance on preferred use? > > 3.5.1.2 Same comment as 3.4.4. > > 3.5.2 Rich representations. Are XML or binary all that are > allowed? I would accept that this may be the case for the DC > XML binding. I think we probably got this wrong. See my reply to your message on DC-Text. > Example 25. Another comment I made about DC-Text. Would > descriptionIdRef be better than descriptionRef. This is just > a question - I don't really have any strong opinion. OK, good. Me, neither! ;-) Thanks, Ann. Pete