XML updated

[Robert Kaye]

Hi!

We didn't get many comments on the XML, but for the few comments we  
did get, we cleaned up the use of attributes in the new XML.  
Attributes are now only used for ids, types and meta-information (such  
as count="2" for track lists).

Please take a look at our updated XML:

    http://wiki.musicbrainz.org/Next_Generation_Schema/XML

--

--ruaok      A village in Texas has its idiot back!

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Paul Taylor-9]

Robert Kaye wrote:

> Hi!
>
> We didn't get many comments on the XML, but for the few comments we  
> did get, we cleaned up the use of attributes in the new XML.  
> Attributes are now only used for ids, types and meta-information (such  
> as count="2" for track lists).
>
> Please take a look at our updated XML:
>
>     http://wiki.musicbrainz.org/Next_Generation_Schema/XML
>
> --
>
> --ruaok      A village in Texas has its idiot back!
>
> Robert Kaye     --     rob@...     --    http://mayhem-chaos.net
>
>
> _______________________________________________
> MusicBrainz-devel mailing list
> MusicBrainz-devel@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>
>  

Could we have an example of something else going into artist-credit
other than name-credit ?

In this section, is there some of ordering of name credits in play to
generate Portishead & Massive Attack, because shouldnt rely on this in
the xml,
<name-credit>
                <name>Portishead</name>
                <artist id="8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11">
                    <name>Portishead</name>
                    <sort-name>Portishead</sort-name>
                </artist>
            </name-credit>
            <name-credit joinphrase="&">
                <artist id="10adbe5e-a2c0-4bf3-8249-2b4cbf6e6ca8">
                    <name>Massive Attack</name>
                    <sort-name>Massive Attack</sort-name>
                </artist>
            </name-credit>

if an ordering is required, an extra position attribute shoud be added
like in tracklist
i.e.
             <name-credit>
                 <position>1</position>        
                 <name>Portishead</name>
                <artist id="8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11">
                    <name>Portishead</name>
                    <sort-name>Portishead</sort-name>
                </artist>
            </name-credit>
            <name-credit joinphrase="&">
                <position>1</position>
                 <artist id="10adbe5e-a2c0-4bf3-8249-2b4cbf6e6ca8">
                    <name>Massive Attack</name>
                    <sort-name>Massive Attack</sort-name>
                </artist>
            </name-credit>



Is there any difference between duration in track, and length in
recording, if not should we use the same element name for both and what
do you see in the xml when the duration is not known, is it displayed as
zero or is the element missing ?

Is there a way to go from track to work, I thought the tracks in the
track list would give at least give a  reference to the work, (i.e what
work does the track belong to)
and also that the recording entity would give the work id.

I assume the & is actually being escaped and were just seeing the
rendered output
i.e the generated xml fo release -group is actually <name-credit
joinphrase="&"> not <name-credit joinphrase="&">

Paul


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

On Thu, Aug 20, 2009 at 1:08 AM, Paul Taylor<paul_t100@...> wrote:
> In this section, is there some of ordering of name credits in play to
> generate Portishead & Massive Attack, because shouldnt rely on this in
> the xml

You can rely on that. XML elements are lists, not sets. We actually
already do rely on that, as the current XML has no explicit ordering
of <track>s inside a <track-list>. If this was not correct, then this
part of XHTML:

<p><a href="#">Click</a><a href="#">here.</a></p>

could be rendered as "here.Click". :)

--
Lukas Lalinsky
lalinsky@...

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Paul Taylor-9]

Lukáš Lalinský wrote:

> On Thu, Aug 20, 2009 at 1:08 AM, Paul Taylor<paul_t100@...> wrote:
>  
>> In this section, is there some of ordering of name credits in play to
>> generate Portishead & Massive Attack, because shouldnt rely on this in
>> the xml
>>    
>
> You can rely on that. XML elements are lists, not sets. We actually
> already do rely on that, as the current XML has no explicit ordering
> of <track>s inside a <track-list>. If this was not correct, then this
> part of XHTML:
>
> <p><a href="#">Click</a><a href="#">here.</a></p>
>
> could be rendered as "here.Click". :)
>
>  

Okay you are right it can be relied on, but it is more problematic to
deal with.

For example in a piece of  my current code that tries to find the best
track in a release, once I have found a match I cannot associate a
position directly with the track because it doesn't have that attribute
, so I have to add a release list to the track with a track list within
it in order to set the offset of the track within. I assume position has
been added as an element of track for good reason, it would make sense
to apply the same logic to name credit.

And are we just relying on implementation detail here.  I found this
link http://www.ibm.com/developerworks/xml/library/x-eleord.html that
talks about elements of different types , (I couldn't find anything
about the order of the same elements) which is saying that elements are
sets not lists and that order is not defined within xml, although you
can specify it in your relaxng schema.

Paul

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Philipp Wolfer-2]

On Thu, Aug 20, 2009 at 1:08 AM, Paul Taylor <paul_t100@...> wrote:

if an ordering is required, an extra position attribute shoud be added

like in tracklist

If we add this I would recommend putting the position into an attribute since this is really not core data but just additional metadata for the parsing application.

For consistency I would put the position into an attribute for tracks as well.
 

Is there any difference between duration in track, and length in
recording, if not should we use the same element name for both and what
do you see in the xml when the duration is not known, is it displayed as
zero or is the element missing ?

I agree that those should be named consistently. I can't see any difference.

 

I assume the & is actually being escaped and were just seeing the
rendered output
i.e the generated xml fo release -group is actually <name-credit
joinphrase="&amp;"> not <name-credit joinphrase="&">

That's for sure an error in the Wiki. I've changed that.

Philipp

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Brian Schweitzer]

On Thu, Aug 20, 2009 at 4:32 AM, Philipp Wolfer <ph.wolfer@...> wrote:

On Thu, Aug 20, 2009 at 1:08 AM, Paul Taylor <paul_t100@...> wrote:

if an ordering is required, an extra position attribute shoud be added

like in tracklist

If we add this I would recommend putting the position into an attribute since this is really not core data but just additional metadata for the parsing application.

For consistency I would put the position into an attribute for tracks as well.
 

Is there any difference between duration in track, and length in
recording, if not should we use the same element name for both and what
do you see in the xml when the duration is not known, is it displayed as
zero or is the element missing ?

I agree that those should be named consistently. I can't see any difference.

 

On these same lines, I'd suggest <name> in recording should be <title>; it's name for artists and labels (and recordings), but 'title' for works, releases, and release-groups, so using 'title' would seem more consistent, as well as easier to avoid confusing the <name> that is the recording, vs the <name> that is the recording's artist(s).  It appears to already be "title", and not "name", when it appears as <medium-list><medium><track-list><track><recording><title> in release info.

In release, is "Latn" a typo?

Last, for the XML, shouldn't artist also have a <disambiguation>?

Also, something schema-wise that I noticed when talking with Oliver this morning.  Why are "label name" and 'cat #" label-info for a release, but "barcode" and "country" are release-info?  If the intent is to support covering those releases which have more than one cat # for a release, I could see a case for either only n:1 cat #:release, with the label, barcode, and country 1:1 to the release (ie, a strict multiple cat #'s per release interpretation), or label/cat#/barcode/country:release all being collectively n:1 (ie, a a more encompasing multiple cat #'s per release interpretation), but having only label/cat#:release as n:1, and barcode/country 1:1 I don't understand.

Brian

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Brian Schweitzer]

In release, is "Latn" a typo?

nikki pointed out to me that this is correct; ISO code, not plain text.

While taking one last look, I noticed one other missing element, in the recording data.  <isrc> is missing from that fragment.

Brian

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Robert Kaye]

On Aug 26, 2009, at 12:51 PM, Brian Schweitzer wrote:
> On these same lines, I'd suggest <name> in recording should be  
> <title>; it's name for artists and labels (and recordings), but  
> 'title' for works, releases, and release-groups, so using 'title'  
> would seem more consistent,

I agree, I fixed this.

> In release, is "Latn" a typo?

No.

> Last, for the XML, shouldn't artist also have a <disambiguation>?

Yes, but these examples are not 100% explicit.

> Also, something schema-wise that I noticed when talking with Oliver  
> this morning.  Why are "label name" and 'cat #" label-info for a  
> release, but "barcode" and "country" are release-info?  If the  
> intent is to support covering those releases which have more than  
> one cat # for a release, I could see a case for either only n:1 cat  
> #:release, with the label, barcode, and country 1:1 to the release  
> (ie, a strict multiple cat #'s per release interpretation), or label/
> cat#/barcode/country:release all being collectively n:1 (ie, a a  
> more encompasing multiple cat #'s per release interpretation), but  
> having only label/cat#:release as n:1, and barcode/country 1:1 I  
> don't understand.

I don't understand either. Could you please restate this in 1/3 of the  
words you used?

--

--ruaok      A village in Texas has its idiot back!

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Brian Schweitzer]

> Also, something schema-wise that I noticed when talking with Oliver
> this morning.  Why are "label name" and 'cat #" label-info for a
> release, but "barcode" and "country" are release-info?  If the
> intent is to support covering those releases which have more than
> one cat # for a release, I could see a case for either only n:1 cat
> #:release, with the label, barcode, and country 1:1 to the release
> (ie, a strict multiple cat #'s per release interpretation), or label/
> cat#/barcode/country:release all being collectively n:1 (ie, a a
> more encompasing multiple cat #'s per release interpretation), but
> having only label/cat#:release as n:1, and barcode/country 1:1 I
> don't understand.

I don't understand either. Could you please restate this in 1/3 of the
words you used?

I can't go shorter, but I'll try for clearer. :)

In the schema,
    release-group-info: type
    release-info: barcode, date, country, status, packaging, language, script
    label-info: label name, catalog number

release_label:release is n:1.  This allows a single release to have multiple labels and or multiple catalog numbers.
  eg: released by Sony & Warner Brothers with cat # 123456
        released by Sony with cat #s 123456 & abc987
        released by Sony & Warner Brothers with cat #s 123456 & abc987

However, date, barcode, and country are release data, not label data, in the schema. 

* If an identical release is released on 2000-01-01, and then rereleased on 2009-01-01, you now need two releases.
* If an identical release was released in France and the UK on the same date, but with two different barcodes, you now again need two releases.
* Or, that same release, with the same date, barcode, cat #, etc, but released in both France and the UK, you still need two releases, due to the different release countries.

I understand that the idea here is to support releases which, on the same liner, have 2 catalog numbers (ie, the Varese Sarabande problem).  However, this still artificially splits the release event data so that in a lot of possible cases, we end up having to duplicate a release, simply because one non-label data detail (release date, country, barcode) is different.

The release_label table doesn't really seem to solve the Varese Sarabande problem cleanly either, as you still get two Varese Sarabande entries, one for each cat #, rather than one VS label entry with two attached cat #s.

It seems it'd make more sense to keep date, country, label, cat #, and barcode together (as a release_event:release n:1), with each field of release_event also being field:release_event n:1; then any cases of "(identical but for different) or (multiple) release date/country/label/cat#/barcode" could have the RE be entered correctly, without any need for duplicating releases.

Brian

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

On Sat, Aug 29, 2009 at 2:30 AM, Brian
Schweitzer<brian.brianschweitzer@...> wrote:

> However, date, barcode, and country are release data, not label data, in the
> schema.
>
> * If an identical release is released on 2000-01-01, and then rereleased on
> 2009-01-01, you now need two releases.
> * If an identical release was released in France and the UK on the same
> date, but with two different barcodes, you now again need two releases.
> * Or, that same release, with the same date, barcode, cat #, etc, but
> released in both France and the UK, you still need two releases, due to the
> different release countries.
>
> I understand that the idea here is to support releases which, on the same
> liner, have 2 catalog numbers (ie, the Varese Sarabande problem).  However,
> this still artificially splits the release event data so that in a lot of
> possible cases, we end up having to duplicate a release, simply because one
> non-label data detail (release date, country, barcode) is different.
>
> The release_label table doesn't really seem to solve the Varese Sarabande
> problem cleanly either, as you still get two Varese Sarabande entries, one
> for each cat #, rather than one VS label entry with two attached cat #s.
>
> It seems it'd make more sense to keep date, country, label, cat #, and
> barcode together (as a release_event:release n:1), with each field of
> release_event also being field:release_event n:1; then any cases of
> "(identical but for different) or (multiple) release
> date/country/label/cat#/barcode" could have the RE be entered correctly,
> without any need for duplicating releases.

I don't think it would make sense. EAN is the identifier of a release,
there definitely shouldn't be more than one. Using multiple
country/date pairs instead of one would be useful in some cases (Nikki
already asked about that), but that's more than I wanted to do in NGS.
Mostly because then we need to decide what is the "primary"
country/date, which adds more complexity.

NGS handles multiple label/catno only because I wanted to handle
correctly the situation when the same identical release has multiple
barcodes mentioned on the cover. It's not that rare to have for
example a release by a small label that assigns it a nice catalog
number, but the label is owned by a big corporation which assigns it a
catalog number based on the EAN. We discussed with Nikki how to handle
CD specific catalog numbers (common on Japanese releases) and the best
idea was to optionally link these label/catno pairs to release
mediums, but I'm afraid this is again post-NGS.

--
Lukas Lalinsky
lalinsky@...

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel