#musicbrainz-devel

brianfreud_: I'm not sure what point you're making.

URI != MBID; UID == domain+entity type+MBID (or, in theory, domain+MBID) ; MBID == UUID + knowledge of that UUID being MB-assigned

So you're saying that an MBID is a UUID + some context?

yeah

I understand what you mean, and I used to think something similar.

The only thing that's really being argued is what the *official* definition of an MBID is, and for that I agree with what I've written on that page.

What about "These relative URIs consist of just the <UUID> portion of the MBID. "?

THe definition that has been used in common conversation has always been that MBID == UUID though.

"I used to think something similar" - I don't anymore.

hmmm

What I think now is what I've edited the page to reflect.

Don't get me wrong, I'm not proposing a change of what we call MBIDs. No way. All I did was edit the official documentation to state the official documentation. :)

How we use the term in conversation is something else entirely.

yeah... actually, re-reading that, I think I agree with you, if I understand... MBID is technically being defined as == the URI, even though the common terminology interpretation of MBID is that it is just the UUID part

nikki: Not a talk page, not a proposal?

And not what is used on IRC ;)

I mean how do we say what mbid officially is?

Hopefully cleaning up the wiki such that anything that is one of ^^ gets marked as such, so that those can't be mistaken as official anymore

nikki: Based on the specs that was drawn up long ago?

you said that the documentation was bad and used both, so now what?

personally, I'd take the definition on http://wiki.musicbrainz.org/MBID as the "most official" definition, and failing that, a definition on some future cleaned up version of http://wiki.musicbrainz.org/MusicBrainz_Termino...

brianfreud_: huh?

<nikki> I mean how do we say what mbid officially is?

brianfreud_: and how we find out what to put on that page? :P

*confused* Is there some need to replace http://wiki.musicbrainz.org/MBID#Definition ? I don't think we need to put anything there; it already has a definition there...

brianfreud_: the whole argument is about what the definition is

oh, I see, that bit is new

nikki: Regarding which documentation is bad and which is good, as far as I can tel the documentation has always said that an MBID is a URI.

and hmm, it's also the opposite of the definition of "MBID (all types) == UUID" from http://wiki.musicbrainz.org/?title=MusicBrainz_...

navap: on some pages, on others it's clearly said the opposite

navap: "All IDs in Music­Brainz are UUIDs. For example: 95807106-af9f-417d-b1d0-d287c5504ec1"?

brianfreud_: Take a look at the individual Entity_ID pages

nikki: http://wiki.musicbrainz.org/MusicBrainz_XML_Met... seems pretty authoritative.

personally, I'd say that the old definition of MBID superceeds the old definition of any of the individual IDs, such as http://wiki.musicbrainz.org/?title=Artist_ID&am...

MBID == URI just doesn't make as much sense as MBID == UUID.

If an MBID is a UUID, you can't do anything with it.

How does 53b106e7-0cc6-42cc-ac95-ed8d30a3a98e mean anything to you?

I quite liked Murdos' example when he made that point.

Point number 1 http://wiki.musicbrainz.org/User_talk:murdos

The point is even clearer when you think of usages of an MBID outside of MB. A UUID doesn't mean anything "out there".

without any context, it doesn't. Within the context of knowing that it came from MB, however, I know it is a unique identifier of a specific MB entity.

Sure, if you have the context. And then what you're looking at is the relative URI.

brianfreud_ probably meant ' Hence my comment earlier that there seems no real reason that musicbrainz.org/uuid shouldn't be made to work, rather than requring the extra step of knowing the entity type, for musicbrainz.org/entity type/uuid '

Hence my comment earlier that there seems no real reason that mb.org/uuid shouldn't be made to work, rather than requring the extra step of knowing the entity type, for mb.org/entity type/uuid

What "could be" and what "should be" and even what "might be", are irrelevant to this converation.

but in that sense, that's the difference between an MBID and an ArtistID, I guess - the MBID defines some unique entity at MB, though without explicitly defining the entity type. The ArtistID, LabelID, etc, all define a specific entity, with explicit entity type, at MB.

http://wiki.musicbrainz.org/MusicBrainz_XML_Met... refers to them as just IDs, I'm not sure when the prefix of MusicBrainz was added to ID - but I can't say I disagree with it.

The oldest use of "MusicBrainz Identifier" I can find is from 2002, and it's used to refer only to the UUID part: http://lists.musicbrainz.org/pipermail/musicbra...

http://oldwiki.musicbrainz.org/MBID?action=reca... dates from 2006, and seems to have been drafted (and gone official) without comment to notice the difference in the definition of MBID

Ah now there's an idea. Rewrite the page so that an artist ID is a form of MBID, just like a PUID and disc ID.

nikki: that looks kind of like http://oldwiki.musicbrainz.org/MusicBrainzTag?a...

navap: it isn't already?

archive.org won't load for me.

It is and it isn't.

Currently the MBID page refers to MBIDs as the URIs that are assigned to the musical entities in the database.

I guess I assumed it, but UUID -> MBID -> ArtistID/LabelID/TRMID/ReleaseID/RGID/etc && UUID -> MIPID -> PUID

Anyway, I just edit stuff to say whatever it should say. If you think MBID is supposed to *only* mean the UUID, then take it up with Murdos as he seems to be the only one strongly opposed to that. Or at least he's the only one voicing their opinion.

Well, it's only a name for something in the schema, but its definition seems kind of central to MB. Since there's decent reason to believe both, depending on when and where we look, perhaps which definition defines MBID is Rob should make a benevolent dictator decision on?

rob already said they're uuids :P

sounds like a decision then :)

Quick nit, something that keeps annoying me... Does the css for the wiki really need to define === as so huge? === is at least 3 times larger a fontsize than the orange bar text of ==

brianfreud_: huh? What browser are you using?

nikki: :)

FF 3.6.2

It should look just fine.

The sizes for h2s and h3s are quite similar. Nowhere near three times larger.

In fact, they're the same size if I'm not mistaken.

hmmm, ah - sorry; the ='s on this page were unbalenced; it was reading it as =

do we have a BigMess category equiv?

You can probably pick any category at random and you'll find it to bea a big mess :)

Well, I'm trying to clean up all proposal and AR pages; http://wiki.musicbrainz.org/Category:Other_Data... is in need of a lot more work

Instead of creating a new category to store stuff that needs fixing, I'd suggest creating a subpage of your user page and use it as a "todo" list.

That ensures that the wiki itself doesn't get more corrupted in the attempt to fix it.

only neg to that approach is that the lists themselves bit-rot; at least auto-generated backlinks clean up after themselves when the mess is fixed

Actually *everything* bitrots, the only difference is where it's bitrotting. Having concent bitrot on your user page is much preferable to bitrotting out in the real wiki.

That's just my opinion based on my travels around our wiki.

The other advantage is that while you're going around finding pages that need work you're not constantly editing them all to add the category - and therefore creating lots of noise. You can make a few edits to your user page and add 20 pages at a time that way, and it's also easier to filter out user page edits.

Sure, though theoretically minor edits like that should be marked as minor, which is also filterable :)

hmm, http://wiki.musicbrainz.org/Wikipedia <-- quick CforD?

brianfreud_: yes

Grrr...

However, several in Discography RC aren't discographic ARs, and most AR in Online Data RC are not exclusively label-URL ARs.

Which is why we had a discussion about renaming the discography class to "External resources"

But since that's a major change it probably needs to go through the mailing list, and until someone does it it won't get renamed.

that'd conflict with Online Database Relationship Class, wouldn't it?

Not if the online database class is merged into it :)

So one huge "External Resources Database Class"?

Can you think of any reasons that might be a problem?

sorry, "External Resources Relationship Class"

not really. A class that huge seems kind of contrary to the point of classes though

Perhaps, but having tons of small poorly defined classes which contradict each other also seems contrary to the point of classes :)

Besides, I don't think a "class" does anything for the user using it.

It'd be 19 ARs - that's the 2nd smallest, next to Production RC... But Production RC is then subClassed (or will be, after the RFC fixes it), so that one class really only has 2 ARs and 2 subClasses; This new Class would have 19 ARs and no internal organization

2nd largest, I mean

When it comes to url relationships, I don't think it makes sense to start overly categorizing them into small sections of the web. I like the idea of one big external resources class.

If that means 19 relationships in one "class", then so be it.

The number is only going to get bigger anyway.

we need to make as many of the url ones auto-detect anyway

+as possible

if you do it for ngs, it won't be out of date as fast :P

I had current schema, then I switched to NGS, then back, now I'm thinking of going back to NGS.

Shouldn't artist have gender listed here? http://wiki.musicbrainz.org/NGS#Data_Dictionary

navap: RFC to clean that mess up drafted and sent :)

I went with one big class, divided into 3 subclasses of 10, 7, and 1 AR ("External Information", "External Website", and "Affiliate")

re: entity pages, I know there's more difficult than the AR pages, but I'm trying to get them current, but with an eye towards making it as easy as possible to update them to NGS once it's in play (essentially, pass a quick RFC, then change "Track" to "Work", or whatever the old/new entity is, and the change will be done)

I have a feeling my version of the entity pages would be quite different from yours :p

lol, I'd prob take them to the list a few times

Hey ruaok, so it went well?

it did. :-)

I'm quite jazzed.

I'm trying to avoid computers though. thats why I've been sparse online this weekend.

Good news :)

:-)

got a sec for me to ping you on your AR?

in a minute. got two convos already.

np

Is noone here a Swedish-native/Swedish-fluent speaker?

or Turkish-native/Turkish-fluent?

:-)

just put in more artificial tears

shouldn't you be during that during work?

eating your own dogfood and all? ;)

ruaok: I listen to stuff which often isn't in the DB, tagging a release can take a while

ah. :-)

it would be ok if it was just 'picard .' => cluster => lookup => save => quit, mv ~/tag/todo/foo /mnt/music/tagged/somewhere

wasn't too bad this time. only had to add 1 disc (of a two disc release), and move two releases to the correct release group.

ruaok: Just since I have to leave to work in a few min (I'll read scrollback), the 2 Qs for you on your AR:

Q1: We'd talked in the dev mtg about "has press coverage" - did you prefer "has news coverage", as you used in the proposal page? The latter sounds more open-ended in terms of what could be linked to.

Q2: Same lines, from Chad: "The original idea for Guardian in IRC talks about linking to tag/index pages on an artist, which might be sensible. The proposal as it reads, and the basic text of the relationship sounds like a free-for-all to link to individual articles, which I don't think would be a good idea. Which is it?"

thx

aCiD2: ping? (i'm having trouble with git)

hi just like artist alias, is there a track and album alias too ?

also why are there like 4 or 5 asian aliases for english names, eg, Michael Learns to Rock ?