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.> 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.> > 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. <artwork uri="#embedded-image" /> Being able to specify resources within an Ogg stream is something that would be useful. -- imalone
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.> > 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. 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?> > 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?)> > <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. Thanks for contributing. -- Daniel Aleksandersen
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
Daniel, Thanks a lot for taking an interest and trying to work with metadata in Ogg. There have been efforts before, but they have seemly gone nowhere. I've heard there's a need for a serious metadata framework in Ogg, albeit me personally would find no use for it. Then again, the Web's moving to a Semantic level, or so they say, hence this will be needed soon or our present efforts will be redundant. Just one minor nitpick: stop writing Ogg as "OGG". Ogg is not an acronym. On 9/8/07, Ian Malone <ibmalone@gmail.com> wrote:> <video encoding="application/theora+ogg" />If this is a media type, as I expect, it should be video/ogg. Without any "+". -Ivo
On Saturday 08. September 2007 16:12:08 Ivo Emanuel Gon?alves wrote:> Thanks a lot for taking an interest and trying to work with metadata > in Ogg. There have been efforts before, but they have seemly gone > nowhere. I've heard there's a need for a serious metadata framework > in Ogg, albeit me personally would find no use for it. Then again, > the Web's moving to a Semantic level, or so they say, hence this will > be needed soon or our present efforts will be redundant.I feel that these ?Vorbis comments? are not sufficient. There is not even a standard for their field names. This XML based format is just meant to push for development of ANY metadata format.> Just one minor nitpick: stop writing Ogg as "OGG". ?Ogg is not an > acronym.It is not? Hm.... I never given it a though. I see ?OGG? everywhere. Look in Wikipedia, for instance. Though the article there uses both forms.> On 9/8/07, Ian Malone <ibmalone@gmail.com> wrote: > > <video encoding="application/theora+ogg" /> > > If this is a media type, as I expect, it should be video/ogg. Without > any "+".I do not know what MIMEs is being used in Ogg. As I have understood it, there is only application/ogg. Anyone that have seen my suggested format will have noticed that I have no idea how to address the various formats. I have assumed it should be possible by using MIMEs and URIs. Please advise. -- Daniel Aleksandersen
On 8 Sep 2007 at 12:07, Daniel Aleksandersen wrote:> 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?For these questions, it might be helpful to have a look at the relationships used in MusicBrainz (for music, at least). http://wiki.musicbrainz.org/PerformerRelationshipType See the linked pages, as well. Unfortunately, the wiki isn't going to give you a very good birds-eye overview of the performance roles available. Try browsing the database, too. -- -:-:- David K. Gasaway -:-:- Email: dave@gasaway.org -:-:- Web : dave.gasaway.org