New thoughts about the Vocal Music Data Exchange Format

Vocal Music Data Exchange Format – Publication #2



Based on the publication #1 (you can download it here: I had a lot of communication with different people, potential users and members of groups, booking agents and IT professionals, music professionals and other interested people.


While talking it through over and over again, looking at it from different angles, I came to the conclusion that, besides being focussed on data types and format on one end, I have to start another parallel thread that is at least as important: Data management.


Similar to the nature of the Internet - where we are aiming to bring our concept to life - the data publishing and provision to the system has to be in a de-centralized way.

The how

The content provider and most likely the rights owner of the information, i.e. artists, groups, teachers, organizations, have to be able to place it where ever they want and "the other parties" pull it from there. The only need for the publisher is to let the receiving party know, where to find it. This is basically the same approach as for RSS or similar feeds.

The why

Same as for the feeds mentioned above, the publisher places and updates the information in one place only. This is a huge advantage comparing to today where he has to keep all information in all places published in sync.

I mean: these people are artists and focussed on their art and not book keeper or IT

People. Simplifying their life is one of the major topics here.

On the other side for the receiving parties: how often does it happen that major changes happen in a group and you still provide the outdated information, just because you are not aware?

Here you just decide, how often you look up for information updates and your webserver pulls all changes accordingly.

The challenge with distributed storage

While thinking the process through and having in mind that a seamless connect between several data objects, potentially coming from different sources, is the key challenge, I again compared to the mechanics of the internet as a highly distributed datapool.

I recognized that there is one central authority not following the distributed approach: the Domain Name Service (DNS) administrating the assignment of Domain names to IP adresses (finally: the computer the domain's information is stored on).

If you request to call for example, the system checks in the register what IP address links with the domain name and advises the requester to retrieve the information from there.

Central Registration Authority needed

We need a central authority just for the purpose to ensure uniqueness of information. This Authority will be used to generate and provide a unique identifier for artist information (let's call it AUID = Artist Unique IDentifier).

Why does it make sense? Imagine the data of a concert by a group called VocalExpress is transported several times from one platform to the other. Unfortunately it ends up at a place where a group of that name is already registered.

How do I know if it is the same group or just one with the same name?

With the AUID attached it is easy to find out. If it matches to the the groups AUID I have in my data already, I can simply link the information together. If it does not, I can refuse the record or I automatically request the matching group’s information via the central authority, add that group to my database and link the concert to it.

Next steps

I have decided to start with a proof of concept now because I want to get the first pieces of information flying as soon as possible and not wait until we have the 100% solution graved in stone. I will keep you posted.

Feel free to get in contact with me in case you want to comment, participate, help or just give some input to incorporate in this piece of work. You can reach me at




P.S. join the #ACAtech forum to participate in the discussion. You can download the complete article here:

Article Category: 
Appears on Home Slide: 
Rate this Article: 
Average: 5 (1 vote)