Hi Terrence,
It feels like we're talking at cross-purposes?
I'm approaching the subject with the idea that metadata is
important in order for people to find (related) information at some later
time.
Interesting and valid point, unfortunately not the point being
discussed.
I think the issue being addressed by Jonathon was not how-to in a WYSIWYG
editor, rather that metadata is not front-of-mind when editing an existing
resource.'
I equate front-of-mindness with visibility, hence reference to an
editing interface that will *show* the metadata records--a wysiwyg
editor. Jonathan's focus was on the author and not the reader. From
the original post:
** The problem **
People updating Web pages often doesn't update the metadata in the header.
The method presents an elegant solution for metadata that is important for
an external audience/end users (who wrote it, when, what's it about, what
else is there, where am I with regard to related documents), as opposed to
the internal management of a collection (similar but slightly or
significantly different to the above).
I was not advocating a separate metadata collection, but rather
that metadata within a single document may be more elegantly
edited/updated if all contained within the <head> of the
document, than when the records are mixed-in with the content.
The leading WSIWYG editor can be extended, with much gnashing of the teeth
and swearing, to provide this type of functionality. In fact, that is a
major selling point.
Moving away from specifics of which tool, the issue is still
educating authors on a practice that is peripheral to writing the
content. To create and maintain metadata requires the author to either
care about metadata it also helps if they *see* the metadata when
editing/updating the content.
The RDF approach requires the author to have access either to the
source code or the means by which they can assign classes to
<span>s. Wysiwyg editors have *not been created to include a
work flow that is optimised for adding metadata records to content in
this manner*.
I think the opposite. Sure, the finer points of the machine readable part
of the record is invisible,
If the incorrect class value is assigned, the meaning of the
record changes. Say for example I accidentally markup the author's
name as the title:
<span class="dc-title">Andy
Kirkwood</span>
At a visual level (i.e. without viewing the name value) it is not
possible to spot the error. It would also be easy to accidentally add
content to a record when editing, e.g.
<span class="dc-title">Andy Kirkwood will be out
of the office until next week</span>
Authors have the opportunity to administer the metadata for their own
content in a simple, relevant way. Again, the popular WSYIWYG editor can
be extended to help less-savvy people.
As far as I'm aware, the cutomisation available does not replace
the need for the author to care about metadata :).
That the RDF method is simple is definitely debatable. How is
adding <span>s to content more or less relevant to an author
than adding records to the <head>?
>The example provided, <
> http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml >,
> re-purposes content as metadata. If the content is edited, the record
could (unintentionally) be deleted, or the content rewritten to
> included the records required
I'm missing something here... this reads like an argument in favor of both
sides: you can delete the metadata or add it?
At a visual level, that the word 'Anna' is a metadata record for
the first name of the author would not be apparent. I might re-edit
the copy from "Anna spoke to Susan on the phone" to
"She spoke to Susan on the phone". By removing 'Anna', I've
remove a metadata record from the document. To maintain the metadata
record I would then need add 'Anna' to somewhere else.
Keeping track of which records have and haven't been entered
would be a nightmare. It's enough as an author to keep an eye on
structure, grammar, spelling, etc.
> -if metadata records are split between the <head> and <body> of a
document, review would likely require a greater degree of
> concentration/quality assurance and/or additional supporting
> technologies (such as a metadata record 'viewer' that would reveal both
conventional and class-based records)
> -etc.
>
> A custom-built CMS, as a companion to a well-supported publishing
process, is still your best bet.
For enterprise sized endevours with a huge budget or significant inhouse
savvy, sure.
Savvy enough to care about metadata, not savvy enough to edit it
when all the records are in the <head>, but savvy enough to pick
through the content and assign classes to spans to approximate
metadata records AND keep track of which records have and haven't been
completed?
An author that is comfortable with adding <span> elements
with class values corresponding to the DC standard is not the
'problem'. It's the person who forgets to add metadata records when
authoring content. Embedding the records within the content does not
make it any more likely that the records will be entered. It just
leads to an amusing situation of having to write content to include
metadata records.
Attempting to approximate a solution using work-arounds and
existing tools is always likely to be less optimal. I'm not suggesting
that budget isn't a consideration, but if metadata records and their
management is important to an organisation, then that's a business
case for either sourcing or developing appropriate tools.
One word: Tags.
Bottom up, ad-hoc, and eventually convergent labelling seems to have a lot
more traction in the wider audience than thesauri, and controlled vocabs.
The traction of tags has to do with ease of implementation. If
it's easy for me (as the content author) to add metadata records and
I'm prompted to add metadata records by the system I'm using, then I'm
more likely to do so.
Lastly, naked metadata will be indexed by (public) search engines, used to
determine relevance, and returned in SERP's.
Here 'Naked metadata' *is* content. Unless the RDF scheme is used
by the search engine algorithm, the naked records will not affect
ranking.
Best regards,
--
Andy Kirkwood | Creative Director
Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
Motive | web.design.integrity
http://www.motive.co.nz
ph: (04) 3 800 800 fx: (04) 970 9693
mob: 021 369 693
93 Rintoul St, Newtown
PO Box 7150, Wellington South, New Zealand
