A sort of personal and general note on this `camp' issue
On Fri, 4 Dec 1998, Ed McNeeley wrote:
> > The notion that there should be a difference between metadata that is
> > embedded versus metadata that is held in a seperate database raises
> > serious problems. To tie the interpretation of metadata to whether it is
> > embedded or exists somewhere 'out there' is a serious mistake that would
> > cripple the potential usefulness of the metadata. Interpretation of some
> > aspects of the metadata would be dependent upon the context, which means
> > it could not be reliably separated from the resource it describes.
> >
>
> I've been saying for a few days that embedded metadata has real
> utility and is also great for demonstration purposes, but I also see
> the problem Stu has defined above and want to be clear that my
> advocacy for embedded DC does not mean I see a difference
> between embedded DC and DC in a database.
Now, during 1998 I would guess that people in Sweden have created about
8000 Dublin Core metadata objects. This cataloging effort should be
compared with the number of items cataloged by Swedish librarians during
the same year, which is about 17000. The statistics for DC is thus
approaching the one for traditional media.
Interrestingly enough the bulk of these DC records are disseminated as
embedded metadata using metatags are BUT they are more often than not
exported on the fly from databases of various kinds. Most DC metadata are
not either embedded or external, they are BOTH.
Since harvesting is a cheap way of populating a database and since it is
almost impossible to sell a database managing system without a WWW
interface, metadata embedding gives us a bit awkward but a very general
transferring metadata between otherwise entirely incompatible systems with
a minimum of development work.
> I thought DC data was DC data wherever it was. I also thought
> that, wherever it was, its purpose was resource discovery. And,
> finally, I thought DC represented a CORE of metadata and that
> local or custom variables and adaptations could take care of non-
> CORE issues. I don't see why the expected variety of applications
> or manifestations of DC this model enables changes that purpose
> or creates a 'different' DC. In my simplistic view of it; the
> applications may vary, but the definition of the core does not and
> the distance (I hope) between 'camp 1' and 'camp 2' is on the
> application level.
I haven't had the feeling that the people alledgly in `camp 2' (whoever
they are) has another idea of the main goal of our efforts, which used to
be, still is, and will remain improved resource discovery. The current
efforts aims at modularity.
The lessons we've learned by implementing the dotty dc thing is that all
projects does not have the same needs as regards (for instance) controlled
vocabularies and additional fields and sub-structure. Modularity is needed
for these purposes. RDF is the best way of achieving this, but the details
in how this should be done is yet to be settled.
The so-called agent proposal is meant to simplifying modularity by pruning
the tree, so to speak. I have not made up my mind whether I endorse the
proposal as presented, but I share the idea behind it. By cutting off
branches close to the root (source, creator and publisher, say) the main
trunk may develop and flourish and branch more vigourously further up.
What can is achievable within the current core will still work, and by
grafting we will even be able to grow different kinds of fruit on the same
tree.
> I've lost it, but Diane Hillman had some comments on Ricky's initial
> post that helped me live peacefully with two (or more) 'camps'.
>
> Drive safe this weekend!
>
> Ed
>
Siggy
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|