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