On Mon, 13 Nov 2000, Ralph Giles wrote:
> On Mon, 13 Nov 2000 16:26:28 +0200
> "B. Eversberg" <[log in to unmask]> wrote:
>
> > What S. Lundberg is describing:
> > >
> > > In my view, to describe such things one need to create a surrogate for the
> > > "real" thing (which usually doesn't exist on the web) and then express
> > > the relation between the object at hand and that "real" thing.
>
> As another example, we've been working on an online recording metadata
> format/database, which generally works this way, with unique catalog
> numbers for artists, collections and recordings. (we also need to keep
> track of separate digital encodings of the same recording.) In our case
> variant listings are handled through manual linkage and assume users
> will search with a listed spelling.
Sounds as you're staff has quite a task to do there... The result will
clearly be of high quality, though.
> We tried to make the format as compliant as possible with the DC metadata
> elements, but as you say, this is an unfinished issue. :)
>
> The current proposal is at http://musicbrainz.org/MM/ and a sample
> implementation (and database) is available at musicbrainz.org. We'd
> welcome any comments on the design.
Are you searching these items as RDF triples?
> [As background, the point of the site is to develop a community-
> edited metadata collection of digital recordings. Primary access
> will be through automated retrieval based on keys generated from
> the recording itself, e.g. a cd player might download and display
> artist and track information for whatever disc it's playing. We
> also hope it will develop into a standard citation system for artists
> and their work.]
>
> As far as RDF encodinggoes , I had proposed a form based on linked groups
> of nodes similar to Sigfrid's example. I was quite taken by the
> knowledge-representation model for RDF presented in the w3c documentation,
> and thought this better reflected the nature of the database design. The
> musicbrainz author felt that couldn't be parsed efficiently and preferred
> a strict heirarchical structure as you can see in the examples.
Nevertheless, your design raises again the criticism raised repeatedly
during the DC-8 against the dc-usage committee's verdict against allowing
URI as an encoding scheme for most elements. The same holds for the strict
hierarchical structure. which was raised several times as functional
requirement on the workshop in Ottawa.
Later today I'll have to sit down and count the number of new issues :)
Please, if you have some 10 minutes left, please review the its current
status on
http://admin.dublincore.org/groups/architecture/issues.html
Yours,
Sigge
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|