[log in to unmask] <[log in to unmask]> wrote:
|A goal stated at Warwick was that whatever we came up with had to work
|with existing software. Asking Netscape to change their browser was out --
|more importatly, asking Microsoft to change Internet Assistant for Word or
|Microsoft FrontPage was out, too.
People using dysfunctional authoring tools will de facto limit themselves to
creating simple metadata that doesn't rely on positionality. Does anyone
really expect the full functionality of DC (or any standard for that matter) to
be available to every author on every platform using every tool? Basic
functionality can be had from faulty tools while enhanced functionality (that
not everyone will need or use) is available from well thought out tools that
will be available sooner rather than later and probably for cheap or free.
I doubt that the tools available are capable of handling any reasonable complex
system for collection-wide metadata collection either which is why I'm building
my own. Specialty tools such as scripts might end up being the best way to
maintain metadata in any reasonably sized digital collection over the mid-term.
Didn't someone (Stu?) ask at WWW5, "How many people fill in those metadata
boxes in MSWord anyway?"
|The external format that Lou, Eric, Michael & I came up with was cleaner
|because it didn\t have to live within HTML 2.0 documents.
Yes, linked rich formats such as that are the ideal way to go. But
well-structured metadata might be duplicable cleanly if META in HTML weren't
EMPTY. Could this problem be solved if META could only contain other META?
|But we _do_ need to put this stuff into HTML 2.0 documents, and in practice
|_cannot_ rely on the META elements in a HEAD not to get reordered, or not to
|get interspersed with other elements such as adverts for the editing software
|used (yes, really).
So long as the element names used in those pernicious META adverts dodn't
conflict with DC element names, this should not be a problem. Smart indexers
could do some syntax checking on ambiguously typed data (such as author) to
ascertain its type as name, e-mail, affiliation, etc.
|Finally, people need to be able to have more than one kind of metadata
|within their documents. Lycos and Yahoo already understand soe
|combinations such as META name=author, but do not understand it to mean
|what would be meant by META name=dc.author, for example.
Which is argument I made to get rid of those ugly prefixes and suffixes
altogether. If the DC'ness of a container were asserted elsewhere than the
data elements themselves, those elements could look to a non-dc aware client
like existing generic metadata. The cleanliness of this approach, to my mind,
outweighs the potential problems from misordered META elements.
-marc
--
|