[vorbis] Re: RDF Metadata Specification

rob at emusic.com rob at emusic.com
Tue Aug 22 16:16:25 PDT 2000



Ralph Giles seyz:

> As I said, the current proposal is much better. I've been wanting to work 
> out the options for encoding our element set in xml before commenting in 
> too much detail, but that's proved complicated. There are a bazillion ways 
> to do it, even within RDF, and no recommended practice so speak of. I have 
> been thinking that full-on RDF is a bit complicated (hello Michael! :) for 
> the player interface and may suggest that we work with a stricter subset, 
> at least for Ogg. settle down. Maybe something along the lines of the 
> 'encoding unqualified dublin core metadata in xml' working draft: 
> 
> http://purl.org/dc/documents/wd/dcmes-xml-20000714.htm 
> 
> This would be upwards-compatible to the full standard, and just a 
> limitation on what can be in a particular file standard until things 
> settle down. This would mean, for example, just having a slew of 
> <dc:contributor> entries, without the <MM:Contributors><rdf:bag> wrapper 
> like in your 3rd example. 

I don't know if I like this. Whenever I've done things that implemented
a subset of features from a full standard, I've gotten bit by my
non-compliance in the end. And in this case you are going to lose
valuable information such as role and roledetail. So, any RDF data that
goes into a vorbis file will become degraded and then if someone pulls
that data back out and uses it elsewhere you have vorbis acting like a
filter that filters out some of the most useful data.

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?

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. The key is to use XQL-like-queries for pulling data
out of an RDF object. The client lib will be released under the LGPL,
and I would like to offer its use (or portions thereof) for Vorbis. The
biggest problem is that the client lib is written in C++, but if we
really wanted to use it for vorbis, we could bang it down to C in a
matter of hours)

> 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

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

<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF xmlns = "http://w3.org/TR/1999/PR-rdf-syntax-19990105#"
         xmlns:DC = "http://purl.org/DC#"
         xmlns:MM = "http://cdindex.org/MM#">

  <rdf:Description>
    <MM:Collection type="album">
      <rdf:Description>
        <DC:Title>Corroded Path</DC:Title>
        <DC:Creator>Network</DC:Creator>
        <DC:Relation numParts="8"/>
        <DC:Identifier albumId="00003C7E at fuss@39A2D955"
                       artistId="00003C7D at fuss@39A2D955"/>
        <rdf:Seq>
          <rdf:li>
            <rdf:Description>
              <DC:Identifier trackId="00003C7F at fuss@39A2D955"/>
              <DC:Relation track="1"/>
                <DC:Title>Hyperventilation</DC:Title>
            </rdf:Description>
          </rdf:li>

          . . .
          
        </rdf:Seq>
      </rdf:Description>
    </MM:Collection>
  </rdf:Description>
</rdf:RDF> 

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)

Hmmm. Lots more of the complexity that you do not like. :-)
 
> <rdf:description about="http://cdindex.org/rdf/album.pl?id=514"> 
>   <dc:title>Mezanine</dc:title> 
>   <dc:creator>Massive Attack</dc:creator> 
>   <dc:relation dc:refinement="has part" 
>                mm:link="http://cdindex.org/rdf/song.pl?id=6185"> 
>     Angel 
>   </dc:relation> 
>   <dc:relation dc:refinement="has part" 
>                mm:link="http://cdindex.org/rdf/song.pl?id=6186"> 
>     Risingson 
>   </dc:relation> 
>   <dc:relation dc:refinement="has part" 
>                mm:link="http://cdindex.org/rdf/song.pl?id=6187"> 
>     Teardrop 
>   </dc:relation> 
>   [...] 
> </rdf:description> 
> 
> I'm not clear on how free we are in what we put as the content of 
> the relation. Part of the point is to be human-readable, so I like 

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.

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



More information about the Vorbis mailing list