#musicbrainz-devel

/

      • navap
        brianfreud_: I'm not sure what point you're making.
      • brianfreud_
        URI != MBID; UID == domain+entity type+MBID (or, in theory, domain+MBID) ; MBID == UUID + knowledge of that UUID being MB-assigned
      • navap
        So you're saying that an MBID is a UUID + some context?
      • brianfreud_
        yeah
      • navap
        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.
      • brianfreud_
        What about "These relative URIs consist of just the <UUID> portion of the MBID. "?
      • navap
        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.
      • brianfreud_
        hmmm
      • navap
        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.
      • brianfreud_
        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 wonders how official is defined
      • nikki: Not a talk page, not a proposal?
      • navap
        And not what is used on IRC ;)
      • nikki
        I mean how do we say what mbid officially is?
      • brianfreud_
        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
      • navap
        nikki: Based on the specs that was drawn up long ago?
      • nikki
        you said that the documentation was bad and used both, so now what?
      • brianfreud_
        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...
      • navap
        brianfreud_: huh?
      • brianfreud_
        <nikki> I mean how do we say what mbid officially is?
      • nikki
        brianfreud_: and how we find out what to put on that page? :P
      • brianfreud_
        *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...
      • nikki
        brianfreud_: the whole argument is about what the definition is
      • brianfreud_
        oh, I see, that bit is new
      • navap
        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.
      • brianfreud_
        and hmm, it's also the opposite of the definition of "MBID (all types) == UUID" from http://wiki.musicbrainz.org/?title=MusicBrainz_...
      • nikki
        navap: on some pages, on others it's clearly said the opposite
      • brianfreud_
        navap: "All IDs in Music­Brainz are UUIDs. For example: 95807106-af9f-417d-b1d0-d287c5504ec1"?
      • navap
        brianfreud_: Take a look at the individual Entity_ID pages
      • nikki: http://wiki.musicbrainz.org/MusicBrainz_XML_Met... seems pretty authoritative.
      • brianfreud_
        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.
      • navap
        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.
      • The point is even clearer when you think of usages of an MBID outside of MB. A UUID doesn't mean anything "out there".
      • brianfreud_
        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.
      • navap
        Sure, if you have the context. And then what you're looking at is the relative URI.
      • MBChatLogger
        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 '
      • brianfreud_
        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
      • navap
        What "could be" and what "should be" and even what "might be", are irrelevant to this converation.
      • brianfreud_
        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.
      • navap
        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.
      • nikki finds http://web.archive.org/web/20020604223053/http://www.musicbrainz.org/tagger/id-intro.html
      • brianfreud_
        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
      • navap
        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.
      • brianfreud_
      • navap: it isn't already?
      • navap
        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.
      • brianfreud_
        I guess I assumed it, but UUID -> MBID -> ArtistID/LabelID/TRMID/ReleaseID/RGID/etc && UUID -> MIPID -> PUID
      • navap
        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.
      • brianfreud_
        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?
      • nikki
        rob already said they're uuids :P
      • brianfreud_
        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 ==
      • nikki doesn't know because she's using navap's ngs-style theme o/
      • navap
        brianfreud_: huh? What browser are you using?
      • nikki: :)
      • brianfreud_
        FF 3.6.2
      • navap
        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.
      • brianfreud_
        hmmm, ah - sorry; the ='s on this page were unbalenced; it was reading it as =
      • do we have a BigMess category equiv?
      • navap
        You can probably pick any category at random and you'll find it to bea a big mess :)
      • brianfreud_
        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
      • navap
        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.
      • brianfreud_
        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
      • navap
        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.
      • brianfreud_
        Sure, though theoretically minor edits like that should be marked as minor, which is also filterable :)
      • brianfreud_ joined the channel
      • alastairp
        brianfreud_: yes
      • brianfreud_
        Grrr...
      • However, several in Discography RC aren't discographic ARs, and most AR in Online Data RC are not exclusively label-URL ARs.
      • navap
        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.
      • brianfreud_
        that'd conflict with Online Database Relationship Class, wouldn't it?
      • navap
        Not if the online database class is merged into it :)
      • brianfreud_
        So one huge "External Resources Database Class"?
      • navap
        Can you think of any reasons that might be a problem?
      • brianfreud_
        sorry, "External Resources Relationship Class"
      • not really. A class that huge seems kind of contrary to the point of classes though
      • navap
        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.
      • brianfreud_
        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
      • navap
        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.
      • nikki
        we need to make as many of the url ones auto-detect anyway
      • +as possible
      • navap is attempting to rewrite the entity documentation pages but can't figure out if he wants to write them using the current schema or the NGS schema.
      • if you do it for ngs, it won't be out of date as fast :P
      • navap
        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
      • brianfreud_
        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)
      • navap
        I have a feeling my version of the entity pages would be quite different from yours :p
      • brianfreud_
        lol, I'd prob take them to the list a few times
      • ruaok joined the channel
      • ruaok returns with new eyes
      • navap
        Hey ruaok, so it went well?
      • ruaok
        it did. :-)
      • I'm quite jazzed.
      • I'm trying to avoid computers though. thats why I've been sparse online this weekend.
      • brianfreud_
        Good news :)
      • ruaok
        :-)
      • brianfreud_
        got a sec for me to ping you on your AR?
      • ruaok
        in a minute. got two convos already.
      • brianfreud_
        np
      • Is noone here a Swedish-native/Swedish-fluent speaker?
      • or Turkish-native/Turkish-fluent?
      • ruaok speaks blonde
      • warp
        laser eyes ruaok \o/
      • ruaok
        :-)
      • ruaok can't see shit atm.
      • just put in more artificial tears
      • warp tags some music before work
      • shouldn't you be during that during work?
      • eating your own dogfood and all? ;)
      • warp
        ruaok: I listen to stuff which often isn't in the DB, tagging a release can take a while
      • ruaok
        ah. :-)
      • warp
        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.
      • brianfreud_
        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?"
      • ruaok
        thx
      • ruaok will ponder
      • ijabz joined the channel
      • warp
        aCiD2: ping? (i'm having trouble with git)
      • djce joined the channel
      • navap joined the channel
      • VectorX joined the channel
      • VectorX
        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 ?