Kia ora,
Sorry to revive an old thread but unfortunately I follow these discussions sporadically...
Andy Powell wrote:
> The bottom line is that the W3C needs to get better at convincing people
> to use RDF and, FWIW, in my personal view there will have to be some
> pretty drastic changes in the way RDF is presented for this to happen.
> Until that happens, DCMI needs to provide help and guidance to those
> people who are choosing not to use RDF.
I agree, and what I think the non-RDF people (well, me at least :-) ) are waiting for is "RDFlite". Just as SGML never really took off until the simpler XML version came along, RDF may not until RDFlite appears over the horizon. It's very common for subsets to be partitioned off to make schemas more consise and less daunting, eg. W3C-DTF, TEI-lite, etc.
Aaron Swartz wrote:
> I think all you'd really need to do is change <metadata> to
> <rdf:Description> and use the qualifier style specified in the DC-in-RDF
> spec.
Andy and Pete's guidelines do indeed come pretty close to RDF - as soon as you enter the namespaces arena you're virtually there. I don't know about other people, but when I first saw "Using Dublin Core in XML" [1] I thought "I can handle that - it's virtually what I would have done in XML anyway except it has namespaces".
I like to think of myself as at least an intermediate XML developer, but I still tremble everytime someone talks of RDF. I'm happy enough using the basics of it, but it's got a whole lot of other elements that I don't think I'd ever use (or could be bothered trying to understand, as I can't see much application for them).
I understand the Subject, Predicate, Object thing underneath RDF, but really I'm only interested in RDF as a well thought out, extensible, standards-compliant container for my XML metadata. I'll likely never convert it into tuples for processing - I mostly use XSLT when I work on the data. But I do want the data to be in an interoperable format so others who interpret tuples can should they choose to.
Creating basic valid RDF/XML data isn't too hard. The hard part is interpretting it. If you want to interpret some XML that starts <rdf:RDF> (or similar) you currently have to be prepared to interpret anything/everything in the RDF spec [2]. Or you have to move to a tuple-processing engine (I find this much more confusing than processing XML, especially if the RDF uses a lot of complex relationships). This is what has held up development in my Web DC harvester - when the DC is in attached RDF/XML (as is done on the dublincore.org site) I could interpret basic, flat RDF OK, but anything beyond that was going to take some major development work.
I suspect a lot of the metadata people create is fairly basic/flat (certainly a lot of DC data I've harvested is, even when qualified DC is used) and XML encoding using a stripped down RDF would likely suffice for them. This gives us the best of both worlds - people can create their metadata in an XML format that isn't too daunting and (hopefully) fits in with the rest of their environment, but the result is valid RDF and it's resulting interoperability benefits. RDF ("original recipe") would still exist for applications with more complex metadata.
My 2 cents worth...
Thanx,
Douglas Campbell
Digital Initiatives
National Library of New Zealand
[1] http://dublincore.org/documents/2000/07/14/dcmes-xml/
[2] http://www.w3.org/TR/REC-rdf-syntax/
|