[ogg-dev] Feedback on XML metadata namespace

[Ian Malone]

Daniel Aleksandersen wrote:
> On Saturday 08. September 2007 11:40:05 Ian Malone wrote:
>> Daniel Aleksandersen wrote:
>>> Hi again list,
>>>
>>> Attached is a much improved version of yesterday's draft. Introducing
>>> the audio:collection:artwork element to deal with album cover graphics
>>> and such.
>>>
>>> After giving it much though; I decided to drop the audio:preformers and
>>> audio:recording elements. They have been replaced by audio:entities
>>> which is supposed to contain all involved organisations and persons.
>>> audio:recording:rights, :date, and other elements related to the
>>> recording have been changed to audio subsets.
>>>
>>> I got a question about the use of URNs for the URI attribute. URNs are
>>> a subset of the URI specification. I know there is no way of resolving
>>> URNs as of now. But I do mean they are a much better way to describe a
>>> physical resource than using a URL. A URN says ‘what’, where a URL says
>>> ‘where’. The x- suffix is present because the ISRC numbering is not a
>>> registered URN name space. Note that any URI can be used. For example a
>>> web music store may set the attribute to point to that particular song
>>> in their online catalogue. Example URI attribute describing a CD by
>>> it's ISRC number in a URN: urn:x-isrc:0123456789
>> With metadata resolving doesn't matter very much anyway,
>> what matters is uniquely identifying the resource.
> 
> ISRC numbers are unique.
> 

Yes, what I meant was, "I know there is no way of resolving
URNs as of now," isn't a problem.  As you say it's down to
how it is used in application.

>>> I have looked closer at the Dublin Core, and MPEG-7 metadata. This XML
>>> format is very much more detailed than any of those formats.
>>> Compatibility and mapping against these older metadata formats will
>>> prove very difficult without loosing functionality of this format.
>>> (Which will make this format worthless.) Thoughts on this, anyone?
>> Dublin Core was probably enough, except there wasn't
>> quite enough flexibility in the defined relation
>> types.  A list of valid role types or a way to make
>> them meaningful to software and still allow extension
>> is important.
> 
> As it is XML, extensions are no problems. Just add a new namespace to the 
> metadata element defining what stuff does.
> 

I mean extension to the list of valid role types,
while preserving meaning for software.

> A list of valid values for the space separated role attribute is indeed 
> needed. But I think this will be very tricky. What roles are needed? Do we 
> need to say that this person/organisation is a drummer or would musician 
> suffice?
> 

This is down to the metadata creator (remember this data
has to be produced somewhere for some purpose).  Allowing
broad descriptions with optional increasing degrees of
refinement would be nice if possible.

>>> I will create a page for discussing this format in the Xiph wiki in a
>>> couple of days. I had hoped to get some feedback and suggestions from
>>> the emailing lists before doing so.
>>> <video encoding="application/theora+ogg" />
>> et cetera, I think you want to avoid duplicating technical
>> metadata like this which is held in Ogg Skeleton. Within
>> a stream anyway, maybe for separate description of media
>> files it might be worthwhile.
> 
> As long as a OGG file can contain more than one media type, we will need 
> different elements for describing them. However audio, image, text, and 
> video elements could be combined into an item element, or something. But 
> that would require another method of determining what kind of media it is. 
> It will also require that all mediatypes will have the same elements. with 
> the current method, it is possible to say that only image and video 
> elements can have a video:resolution and image:resolution child. Combinding 
> them to one element would open for describing an audio file's resolution. 
> (See the dilemma?)
> 

Yes, that's why I think that leaving that kind of metadata in the
more machine-readable places like Skeleton is appropriate.  If it's
necessary to produce external descriptions then appropriate
whatever existing XML spec is used to describe media formats and
add it in.  Besides the availability of a tag that doesn't make
sense for the described resource isn't really a dilemma.

>>> <artwork uri="#embedded-image" />
>> Being able to specify resources within an Ogg stream is
>> something that would be useful.
> 
> This would point to an image element with a id="embedded-image" within 
> the .ogg.
> 

This needs more support.  CMML already uses fragment identifiers
to label clips and there is also a need to be able to find the
labelled resource.

-- 
imalone