[vorbis] Re: RDF Metadata Specification

[Ralph Giles]

On Tue, 22 Aug 2000 rob at emusic.com wrote:

> On the other hand, I understand the constrictions to not include the
> full kitchen sink as far as RDF and XML are concerned. I feel that if
> you cannot be fully compliant to a standard, its best not to attempt
> being compliant at all.
> 
> Can you please elaborate on your hesitation with RDF? Are you trying to
> keep things simple (ie, a list of metadata key, value pairs) as opposed
> to having metadata that has lists of lists of metadata key, value pairs?

I was trying to keep the syntax simple, but I think you're right about
about the non-compliance thing. Michael has been making this point all
along. We can be normative in what we write, but not what we read.

Hmm. There's been much discussion on the the dublin core lists over the
idea of 'application profiles'. The idea is that, yes we have some element
sets, and yes we have RDF. We might even have a schema that combines the
two in a reasonable way. But there are still going to be practices within
a given application that aren't explicitly specified, something on the
level of 'processing expectations' that are best encoded in words. (or
examples.) Maybe that's a helpful way of thinking about what we're trying
to do here.

BTW, I've heard a rumour the RDF syntax is going to be revised to
merge it with the ISO HyTOP format. (and as a chance to remove some
ugliness). This, and the general flux of things are making me expect we'll
want to revise this in 3-5 years.

> Have you taken a look at the CD Index client library? (This will become
> the musicbrainz client library after burning man) I've managed to
> abstract out all aspects of RDF/XML from the user who might want to
> access the RDF data.

Implementation, cool! :) I'll take a look.

> > The 'role' and 'roledetail' qualifiers are very clever. One issue with 
> > film (or any large production, rather) is that there are often subgroups 
> > under the credits, like "Malta Unit" or "Post Production". I'd suggest we 
> > just use 'roledetail' for this, but maybe other options are better: 
> > 
> > <dc:contributor role="Producer" roledetail="Executive"> 
> >   Herman Mayer 
> > </dc:contributor> 
> > 
> > vs. 
> > 
> > <dc:contributor role="Artistic Director" roledetail="Post Production"> 
> >   Laura NDualle 
> > </dc:contributor> 
> > 
> > I like the second better. 
> 
> I'm not sure that I clearly see the difference between these two. I
> think I like the first one better, where we have fewer defined canonical
> roles, and leave the definition of the roleDetail completely open.
> 
> For instance, I could see pairs like these:
> 
> Role:          RoleDetail:
> Producer       Executive, Malta Team
> Producer       Executive, Hollywood Team
> Producer       Assistant, Malta Team

Right, this is somewhat obsessively nitpicky. My question was just how to
divide the various bits of the credits. having role be something simple
like 'Producer' or 'Director' lets one "dumb down" in a sense, but then
what do you do with 'Director of Food Services'?

Another approach would be to wrap each team/unit in an <rdf:Seq> type or
something from MM and do the extra labelling that way.

> > Another issue is I don't think the x-DonutGopher thing makes sense. There 
> > are *a lot* of roles credited in film, and they change over time. We can 
> > try to maintain a canonical list with some mappings, but we'd always be 
> > playing catch-up with the x-SystemsWranglers. Better not to try and accept 
> > the chaos at the frontier. The industry itself will establish practice, 
> > and we can follow that after the fact. 
> 
> I don't think this will be an issue if we define the Roles to be broad
> enough and leave roledetail completely open for people to add their own
> slant.
> 
> > I suggest replacing MM:Album with a dc:relation link to a new resource. 
> > These have to be separate records in your database anyway, and I think it 
> > makes more conceptual sense to treat them separately in terms of metadata. 
> > I'd been thinking you'd just dump the album metadata into a second 
> > <rdf:description> section, but after writting the example below I think 
> > you could get away without it. 
> 
> I've come to the conclusion that a seperate description for the album is
> the way to go:

I certainly agree with that.

> [example snipped]

> Note the use of MM:Collection. This element is intended to convey
> information about albums, playlists and other lists of lists of metadata
> that might be used outside of Vorbis. For instance, EMusic would like to
> publish the metadata of its entire collection for anyone to download.
> Using the MM:Collection (a more generic term for MM:Album) I can now
> describle playlists, (type="playlist") or any other collection that
> might have multiple levels (for instance, at emusic we may have a list
> of labels with a list of genres for each label, and then a list of
> albums for each genre, and of course a list of tracks for each album)

> As stated above, using the relation for this is inappropriate. There is
> a ton of metadata that applies to a track (just as it does to an album)
> and a sub description is really called for.

I really like being able to treat playlists, collections, anthologies and
so on on equal footing with albums. Could you explain a bit more about why
this is better than my suggestion of using <dc:relation> as a link to
separate record?

In case it wasn't clear from the example, I was quite taken by the RDF
model of a knowledge representation *graph*, while your approach seems
more tree-like. My idea was to have numerous separate records: some for
songs/tracks/files, one for each person/artist/group, and one for each
collection. Then we use implicit pointers to link the records up. A song
record might have <dc:creator>Neil Young</dc:creator> but elsewhere
there's an <rdf:Description about="#Neil%20Young"/> that tells us more
about him. The list of <dc:relation> elements in my example were supposed
to be links of this sort between the song and album records.

This also more closely matches how I'd set up the database.

> Hmmm. Lots more of the complexity that you do not like. :-)

Heh. I don't think we'd need all of this in an Ogg header, but data
interchange is way important.

 -ralph

P.S. What are "Mechanical Rights"?


--
giles at ashlu.bc.ca
Open source licensing is just a formal way of stating that the only
asset that any company or project has is the people involved in it.
  -- Michael Bernstein, http://technocrat.net/966470710

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.