On Mon, 11 Aug 2003 22:33:57 +0100
Andy Powell <[log in to unmask]> wrote:
> On Wed, 4 Jun 2003, Dave Beckett wrote:
> > Changing from DC. to DC: is a bad idea.
>
> Dave,
> thanks for the comments and apologies to all for the length of time this
> reponse has taken.
>
> > The main reason is that it makes people think that the
> > 'dcterms:modified' things inside HTML are XML Qualified Names (Qnames).
> >
> > This will be
> > - confusing since no part of HTML or XHTML uses QNames yet
> >
> > - suggest that these QNames work like XSLT, XML Schema, etc. - they
> > do not and are just strings here.
>
> OK, these two arguments are very persuasive.
Good!
> > - QNames in attribute values are tricky from web architecture point
> > of view and introducing them without careful thought is hard
> > Using Qualified Names (QNames) as Identifiers in Content
> > http://www.w3.org/2001/tag/doc/qnameids.html
> >
> > - not necessary, dc. works just fine and is deployed
>
> For the record, both forms (DC.title and dc:title) are deployed - largely,
> I suspect, because implementors expect the HTML meta syntax to look like
> the XML syntax. I'm not endorsing this - it's just an observation.
yes, but let's not codify the dc:mistake
> > In particular this will likely be conflicting with some emerging work
> > to see how to better embed metadata inside HTML & XHTML that has been
> > going on at the W3C between the W3C and RDF groups. This is looking
> > at how to ship things encoded in the RDF family (RDF, OWL, CC/PP, DC,
> > FOAF, CC, ...) inside HTML. Dublin Core is a very important
> > vocabulary for RDF and I want to make sure it doesn't take a
> > conflicting path.
> >
> > This work has been emerging quietly in the last few months but hasn't
> > yet got anything public to show. I'll give some pointers to earlier
> > discussion[*]
>
> It seems very unfortunate that this work can't be (or isn't being) shared
> on this list - it looks pretty critical to DC-Architecture :-(
On 4th June it wasn't public, but in the last two months, it has been
taking place on a public list. Still ongoing.
> I'd be interested to know the current status of this work. Looking
> around, it's not easy to determine where things have got to (at least from
> outside W3C).
There is no output document just yet, but from my perspective, I
was concerned for DC that the key thing to preserve with RDF & HTML
together was validation. It seemed to me that it was what kept being
required. So, some thought has gone to making validators handle
mixed RDF & HTML - i.e. new validators.
> > <meta rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
> > <meta name="dc:title">RDF/XML Syntax Specification (Revised)</meta>
> > <meta name="ex:editor">
> > <meta name="ex:fullName">Dave Beckett</meta>
> > <meta name="ex:homePage">http://purl.org/net/dajobe/>
> > </meta>
> > </meta>
> >
> >
> > This immediately conflicts with the DCQ-HTML approach since you can't
> > tell which one you are dealing with and will stop these approaches
> > (strawman approach) being interoperable.
>
> I presume that the head profile URI will indicate which approach is being
> used?
I'm not sure. <head profile=".."> isn't widely known about.
> > I'd prefer you stick with 'DC.' (or 'dc.' if you must change)
>
> OK, I reverted to use of the 'DC.' and 'DCTERMS.' form throughout. I'm
> disappointed at having to do this but, as I said above, the technical
> argument you put forward above has pursuaded me.
>
> The revised draft is at
>
> http://www.ukoln.ac.uk/metadata/dcmi/dcq-html/
Your site isn't working right now, I'll have to look later. maybe
you could put this somewhere on the DCMI site?
> I would now like to move this to proposed recommendation status. Please
> respond this week if you think this should not happen.
That's rather sudden. You can't just go away for months and expect such
things to be decided in a week. It's holiday season in the northern
part of the world. You should really wait for several weeks for
feedback - and this applies to your other drafts too.
> Final note: I haven't updated the abstract model in section 2.1 of this
> document in line with the DC Abstract Model WD I sent earlier today. I
> don't want these two documents to lock each other out. At some point in
> the future, and assuming that the DC Abstract Model draft moves thru the
> DCMI process, this section will need updating to reflect the newer version
> of the abstract model - but that change won't significantly change the
> rest of the document. (In fact it will improve it because it will make it
> clearer that some values are URIs - value URIs - and some are strings -
> value strings).
Dave
|