Vocal Music Data Exchange Format

11 posts / 0 new
Last post
acappellamaniac
Vocal Music Data Exchange Format

As the discussion starts to evolve and it happens at multiple places, not to be overseen by all interested people, I would like to start the discussion here.
Basis is the paper about a vocal music database exchange format that has been posted at multiple places, written by myself.
You can find it here: http://europeanvoices.org/content/vocal-music-database-exchange-format
or you download it here: http://europeanvoices.org/filedepot_download/22/4.
So welcome to the forum, welcome to the topic and I have to say that I'm really excited about the coming fruitful discussion, thoughts, brainstomrings - and results.
 
Volker

Florian Städtler
Random Findings of Data Collections

Hi there, 
I will just add any existing database-like websites here, as this might help to discuss the infrastructure, Volker suggests.
Here are a few links:
http://acalist.com/groups (USA)
- https://www.casa.org/acapedia (USA, hosted by www.casa.org)
- www.acappella-online.de (GER, AUT, SWI)
 
FSt/Florian

Florian Städtler
European Voices Association (EVA)
Chairman of the Board
e-mail: florian@europeanvoices.org
skype: florianstaedtler
phone: +49 761 38 94 74
 

michaelmarcus
More people and sites

I think Craig Martek (who runs AcaList) might be interested in this project as well. Likewise Sebastian Wolff, who runs Wikipella as well as ACR/Loudr
Both of those sites are also database-driven, as is RARB (which I run). So that's three more links to reference.

acappellamaniac
New publication online

Just to let you guys know, I have just uploaded publication#2 reg. the topic.

You can read it here: http://europeanvoices.org/content/new-thoughts-about-vocal-music-data-ex...
or download it as PDF here: http://europeanvoices.org/filedepot_download/22/7

Best Regards,

Volker

michaelmarcus
Doubts about need for AUID

Great article, Volker. I like your analogy to DNS, but DNS is in fact distributed -- when I ask my browser for www.cnn.com, a request goes out to one of several DNS servers configured upstream of me, either by me (on my computer or home router), or my ISP. That DNS server, in turn, may need to ask the "authoritative" nameserver for the domain if they don't already have an entry in its cache. It is only the "authoritatve" name server that is maintained by the central DNS registrar.
This is all to say that I don't think a centrally managed AUID is necessary... provided you maintain the assumption that the owner of the information has a website (i.e., a domain name) and thus an "authoritative" source for said information. Other sites may maintain their own copies of the data, but if the TTL has expired or if they don't have a copy, they will need to ask the authoritative source.
We may still need some sort of GUID for the data, but this can be randomly generated by each creator independently and will be guaranteed unique for all practical purposes.

acappellamaniac
Happy to keep that generated GUID distributed, but ....

Hi Michael,

thanks a lot for the feedback. I agree that - assuming an artist/group has a website - potentially the domain name + a generated ID would be sufficient. In case the owner of the domain changes it would also generate a new ID for the new group. But what if it goes the other way around? What if the same group changes his domain for whatever reason? Do you want to stick to the old GUID with the "wrong" domain name in it? If not, would that mean for the system that it is seen as a new group instead of just a different place for the same one? How do we manage that "move"?

One additional topic from my point of view is that in between many groups don't even maintain their websites on a separate webspace but instead just having facebook/myspace/soundcloud appearances and maintain the information there? Is that still compatible?

Happy to hear form you .....

Best Regards,
Volker

acappellamaniac
One additional thought.....

Michael,

you mentioned in your post that DNS is distributed. I'm not agreeing to that opinion. As you write, there is a final "authorative" nameserver maintained by the central DNS registrar. The "individual" DNS servers are basically just caches or shadows of the main one, having some clever mechanizm how to handle unknown requests (i.e. requesting it from the authorative instance), but they are stil just copies of the centrally hold information, avoiding the need of one machine to answer all requests.

In my design I have already forseen to have the possibility to have multiple instances of the AUID provider in different locations running, syncing in a defined interval. And my idea does not plan to have the AUID regitration authority pinged with every single request coming. It is just to provide the AUID and get pinged for missing information and/or validation requests. The normal processing is always a direct one between the information provider (artist/group) and the receiver (online portal etc.)

Best Regards,
Volker

 

Joseph Antonioli
Ask a Librarian...

Volker, thank you for cluing me into the conversation. Just a heads up that I am talking with a few academic colleagues about this. Librarians have spent centuries figuring out how to categorize and organize information, I am sure there input will be valuable.
Best,
Joe

acappellamaniac
any input is appreciated ;)

One additional aspect to ask would be how they deal with keeping distributed information updated and make sure it is unique?

Rince
The (for us :) easiest way is

The (for us :) easiest way is to say that every group / location / whatever has his unique ID and uses only this to update his information. This is the second half of a Identifier, where the first part is offered by the organisation which edits the dns-zonefile (registrar?).
I think with all other aspects we get into trouble quite soon - groups with the same name but different countries, groups who change their name, groups who change their members and the style...
We need one attribute which stays in one group even when everything else changes. This information has to be public and visible so that the groups itself have no trouble finding this ID in case they want to make changes in their information.

Rince
DNS or other distributed channels

Hi guys,

Thomas mentioned this thread to me and I'd like to play around with the idea of having some kind of distributed database for all the information we want to make public.

I think the idea of using DNS is quite well, especially since we could (if we want to) use the txt-fields of the zone-information in a defined matter. I am not sure yet wether we need to modify the DNS-protocol for our needs, but at least the distribution mechanism is IMHO a good way to start.

I think we need at least three different objects: Groups, Festivals / Activities / Concerts and Location. The groups can be more or less static, because the group itself may change but these changes are not often and will need preparation. Then we have Locations which usually don't change.
The objects with the most frequent changes will be the concerts - and I think we need to have a separate object for them, since they will be referenced by groups and locations. Maybe we should also have some kind of meta-concert for festivals, which can include other concerts.
With the Location you have Geodata, which means you can check what will happen in your hometown according to concerts, referenced to the location which has the geodata.
With the groups (or the meta-concert ;) comes the concerts because the groups should have their schedule and can reference their concert to the location.

Does this make sense so far?
For me the main problem is entering the information - and not by me, but by the groups or the one willing to share this information. In my humble opinion we need a good and easy-to-use GUI for this. The technical background (DNS and so) is more or less easy as long as we use the original DNS protocol, but the human interface will be the hardest part.

Ciao, Hanno

totallyrandomthing