[vorbis] Re: RDF Metadata Specification

[rob at emusic.com]

On 23 Aug, Ralph Giles wrote: 
> 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.

I agree -- the current (and soon to be revised) RDF spec still leaves
tons of room for interpretation. My next step (after Burning Man!) will
probably to take a stab at RDF schemas to try and further refine the use
of the RDF spec.

> 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'?

Role: 'Director' RoleDetail: 'Food Services'

No?

> 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?

I'm not completely convinced that MM:album is better -- the jury is
still out on that one. This issue is the main sticking point for me
update the spec -- I haven't completely made up my mind on this yet.

> 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.

I see where you're going with that. However, you are stumbling across
the limitations that I am placing on my design in order to make it
accomplishable in the near future. We're both doing the same thing, but
in different ways. :-)

The idea of dealing with multiple RDF objects that have links between
them significantly increases the amount of work that needs to be done in
order to address the data in the RDF objects. If you look at cdi_client
you'll see that all the data acess/data selection is done with
*simple* XQL queries. With multiple objects you need to teach this query
system to jump through links and do indirect data references.

I believe that the graph idea is more powerful than the tree
approach. But as far as I can see it, all of the power gained by the
graph approach (to describe one resource) is largely lost on
MusicBrainz/Vorbis.

Now, all of this pertains to having one RDF description for one
resource. MusicBrainz will of course use DC:Relation and MM:link to link
to related resources -- I'm just trying to avoid the complicating the
data access system for a single resource description.

>> 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.

I'm glad to see that we see eye-to-eye on this point now.

> P.S. What are "Mechanical Rights"?

Mechanical rights are the rights that govern music being put onto a
'mechanical' piece of media, such as a CD, tape or record. In order to
duplicate a CD you need to have the mechanical rights to the CD (along
with a bunch of other rights I'm sure)

--ruaok         Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye -- robert at moon.eorbit.net  http://moon.eorbit.net/~robert

--- >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.