What do you expect from a social networking site and for what reasons would you use it?

We have already created a small list at:
https://github.com/renepickhardt/metalcon/wiki/requirementsBand
which I am sharing here and asking musicians to contribute to. Eather here in the comment section or via the github wiki. Thanks a lot

Self promotion

Bands want to advertise their music and get a lot of attation.

Music hosting

Bands often lack technical knowledge to host their music. Metalcon can provide them with the functionality to host promotional songs and also share the player on other websites and with other services.

Control

The worst that could happen to a band is that they spend a lot of effort building up their fan base on a social networking site like they did in the early 2000s and then the site becomes irrelevant. Similar problems hold with facebook where page owners nowadays have to pay money to get their message spread to everybody who liked the fan page.

Therefore a requirement for musicians is to keep control of their fan base that they have grown so far.

Contact with fans and Streetteam

Bands want contact to their most important fans and to people who can organize stuff for them. Heaving a streetteam is essential to the sucess of many bands. Using a social networking service can help the band to fulfill their goal

Privacy

Famous musicians want to use the band profil of a social networking site without revealing their private account.

Staying in contact with other industry players

Musicians might want to stay in contact with partners from

• labels
• booking agencies
• promoters
• photographers
• video producers
• music producers
• venue owners
• …

Sell products

Bands want the possibility to sell

• Tickets
• Merchandise
• Music (MP3 and CD)

Booking

Bands want to get the opportunity to book gigs. Giving them the opportunity to get in contact with bookers will help them.

release Management

Bands often have a complete produced record. This should be shared with some players from the industry. In this process the music should be

• hosted in the web
• watermarked (to prevent leaking)
• shared privately with selected partners
• only be streamed from the web

Max report on semantifying

• DBPedia resources are to be linked with “resources” in the URI not with “page”
• SMW requires the pre-fix “foaf:” or “mo:” or something else for EACH imported property
• Check the Special:ExportRDF early to see if your properties work
• Properties / Predicates , no difference with SMW
• How to get data to freebase depends on the backlinks and sameas to other ontologies as well as entering data in semantic search engines
• Forms for user data entry are very important!
• As a non-scientific person without feedback I would not have been able to implement that.
• DBPedia and music ontology ARE not interlinked with SAMEAS (as checked on sameas.org).
• Factbox only works with the standard skin (monoskin). For other skins one has to include it in the PHP code oneself.

Main article

The online wiki Rock in China has been online for a number of years and focusses on Chinese underground music. Prior to starting implementing Semantic Mediawikia our wiki had roughly 4000 content pages with over 1800 artists and 900 records. We used a number of templates for bands, CDs, venues and labels, but apart from using numerous categories and the DynamicPageList extension for a few joints, we were not able to tangibly use the available data.
DPL example for JOINT between two Wikipedia Categories:

<DynamicPageList>
category = Metal Artists
category = Beijing Artists
mode     = ricstyle
order  = ascending
</DynamicPageList>

{{SemanticVenue
|Image=
|ImageDescription=
|City=
|Address=
|Phone=
|Opened=
|Closed=
|GeoLocation=
}}

As can be seen from the above template both predicates (City) and properties (Opened) are being proposed for the semantic class VENUE. Semantic Mediawiki is implementing this decisive difference in a very user-friendly way by setting the TYPE of each SMW property to either PAGE or something else. As good as this is, it somehow confuses if one is talking with someone else about the semantic concept in principle.
A major problem had been the implementation of external ontologies which was not sufficiently documented on the semantic mediawiki page, most probably due to a change in versioning. Especially the cross-referencing to the URI was a major problem. As per Semantic Mediawiki documentation, aliases would be allowed, however with trial and error, it was revealed that only a property with a domain prefix, e.g. foaf:phone or owl:sameas would be correctly recognized. We used the Special:RDFExport function to find most of these errors, everytime our URI referencing was wrong, we would get a parser function error.
First, the wrong way for the following two wiki pages:

• Mediawiki:smw_import_mo
• Property:genre

Mediawiki:smw_import_mo:

http://purl.org/ontology/mo/ |[http://musicontology.com/ Music Ontology Specification]
activity_end|Type:Date
activity_start|Type:Date
MusicArtist|Category
genre|Type:Page
Genre|Category
track|Type:String
media_type|Type:String
publisher|Type:Page
origin|Type:Page
lyrics|Type:Text
free_download|Type:URL

Property:genre:

[[Has type::Page]][[Imported from::mo:genre]]

And now the correct way how it should be actually implemented to work:
Mediawiki:smw_import_mo:

http://purl.org/ontology/mo/|[http://musicontology.com/ Music Ontology Specification]
activity_end|Type:Date
activity_start|Type:Date
MusicArtist|Category
genre|Type:Page
Genre|Category
track|Type:String
media_type|Type:String
publisher|Type:Page
origin|Type:Page
lyrics|Type:Text
free_download|Type:URL

Property:mo:genre:

[[Has type::Page]][[Imported from::mo:genre]]

The ontology with most problems was the dbpedia, which documentation did not tell us what the correct URI was. Luckily the mailing list provided support and we got to know which the correct URI was:

http://www.dbpedia.org/ontology/

Being provided that, we were able to implement a number of semantic properties for a number of classes and start updating our wiki pages to get the data on our semantic database.
To utilize semantic properties within a wiki, there is a number of extensions available, such as Semantic Forms, Semantic Result Formats and Semantic Maps. The benefits we were able to gain were tremendous. For example the original JOINT query that we had been running at the beginning of the blog post with DPL was now able to be utilized with the following ASK query:

{{#ask: [[Category:Artists]] [[mo:origin:Beijing]]
|format=list
}}

However with the major benefit that the <references/> extension would NOT be broken after setting the inline query within a page. Dynamic Page List breaks the <references/>, rendering a lot of information lost. Other examples of how we benefitted from semantics is that previously we were only able to use Categories and read information of joining one or two categories, e.g. Artist pages that were both categorized as BEIJING artists and METAL artists. However now, with semantic properties, we had a lot of more data to play around with and could create mashup pages such as ROCK or Category:Records on which we were able to implement random videos from any ROCK artists or on which we were able to include a TIMELINE view of released records.

Owl:sameas (or sameas)

On various of our pages directly to Wikipedia pages.
However we learnt that the property

foaf:primaryTopic

is a much better and accurate property for this. The sameas property should be used for semantic RDF pages, i.e. the respective DBPedia RESOURCE page (not the PAGE page). Luckily we already implemented the sameas property mostly in templates, so it was easy enough to exchange the properties.
Having figured out this issue, we checked out both the freebase page as well as other pages, such as DBpedia or musicbrainz, but there seems to be no “submit RDF” form. Hence we decided that the best way for getting recognized in the Semantic Web is to include more links to other RDF resources, e.g. for our Category:Artists we set sameas links to dbpedia and music ontology. For dbpedia we linked to the class and for music ontology to the URI for the class.
Note on the side here, when checking on sameas.org, it seems that music ontology is NOT cross-linked to dbpedia so far.
Following the recommendations set forth at Sindice, we changed our robots.txt to include our semantic sitemap(s):

Sitemap: http://www.music-china.org/wiki/index.php?title=Special:RecentChanges&feed=atom
Sitemap: http://www.rockinchina.com/wiki/index.php?title=Special:RecentChanges&feed=atom

Going the next step we analyzed how we can include external data on our SMW, e.g. from musicbrainz or from youtube. Being a music-oriented page especially Youtube was of particular interest for us. We found the SMW extension External Data that we could use to connect with the Google API:

{{#get_web_data:
url=https://www.googleapis.com/youtube/v3/search?part=snippet&q=carsick+cars&topicId=%2Fm%2F03cmgbv&type=video&key=Googlev3API&maxResults=50
|format=JSON
|data= videoId=videoId,title=title
}}

And

{{#for_external_table:
{{Youtube|ID={{{videoId}}}|title={{{title}}} }}<br/>
{{{videoId}}} and {{{title}}}<br/>
}}

See our internal TESTPAGE for the live example.
Youtube is using its in-house Freebase ID system to generate auto-channels filled with official music videos of bands and singers. The Freebase ID can be found on the individual freebase RESOURCE page after pressing the EDIT button. Alternatively one could use the Google API to receive the ID, but would need a Youtube internal HC ID prior to that. Easy implementation for our wiki: Include the FreebaseID as semantic property on artist pages within our definitions template:

{{Definitions
|wikipedia=
|dbpedia=
|freebase=
|freebaseID=
|musicbrainz=
|youtubeautochannel=
}}

Voila, with the additional SQL-based caching of request queries (e.g. JSON) our API load on Google is extremely low as well as increasing speed for loading a page at our wiki. Using this method we were able to increase our saved YOUTUBE id tags from the original 500 to way over 1000 within half a day.

Filip: Even though I wasn’t agreeing with your Facebook skepticism in the beginning, I realized that I was overestimating Facebook in its promotion role. I’ve been creating extremely successful, targeted (extremely low budget though – just 5 or 10 euros at a time) campaigns for my band on Facebook.

Results?

Even though I managed to inflate the number of fans (with 12 fans/1 euro average), the interaction stayed the same. These campaigns aren’t entirely useless, though – having this number of fans or more looks nice in a smaller Croatian market and can help in booking bigger shows (thus getting to more fans)..but still dissappointing. I won’t campaign until we release a website/album/have something to sell.

Rene: I like your observation. The first was that gaining these paid likes does not really increase interactions and increase your reach. As I am saying to the In Legend guys all the time: “Money invested in facebook or even effort in facebook reach is not the best way to increase one’s reach” I am very glad that you came to the same conclusion and shared your insights!
Secondly I partially agree with the effect of large fan numbers while booking gigs. It certainly looks good to business partners like bookers, labels, distributers,… if your social media numbers burst. But again I would say the price is too high. With 1 Euro / 12 fans you would need to invest 1000 Euro for 12’000 fans an 12’000 isn’t even skyhigh (well I don’t know about croation standards). But as we know only a very small fraction of these 12’000 fans would actually become real fans and start interacting with you. All this for getting a gig! I guess this money could much better be invested in a high quality video which especially for a young band is a very good investment. With the video in combination with smart music downloads you will be able to increase your reach. Maybe not to 12’000 fans but still to a solid number of real fans that actually come to your concert because they really care! In this way your social media fancount (especially facebook) will also grow.

Filip: Question1 – sharing music!
About the thesis of providing music only on the band site – I think it’s hard for someone to become our fan if there is no music on Facebook. Choosing one song for preview and directing a fan to .com might work, but they are attracting entirely different audiences – think poppy indie rock vs. oriental, modern metal ballad. Is it okay to let this promo run free and spread like wildfire until the album release? Or should I provide 2/3 of songs for free, and ask for a mail adress for the 3rd one? This might be a good model.

Rene: I agree with what you say. At the time of writing the blog post you are referring too I wasn’t aware of the existing facebook music apps. The important thing is getting a sustainable contact to the person interested in your music. This is achieved ultimately by his email adress. But your question is very important. Of course you have to give people a bait. This could be

1. snippets
2. entire song(s) on streeming
3. a music video (In legend offers downloads under every music video)
4. a free download (without registration)

and I really don’t know where to set the boarder.
In the beginning times of In Legend we had 3 songs for streaming on myspace and 4 songs on the ep for download in exchange of an email adress. That turned out to be a good solution. People who liked the first songs where curious to download them together with one additional song. So I guess a 2/3 split would work as well. I will just warn you. Asking people for their mail address scares 4 of 5 people away. But hey at least you get the adresses of your fans that are really willing to give something for the music!
Now about the place where to make the connection. If you achive getting the fans mail adress via a smart Facebook music player or via download on your homepage I don’t care. Once people like your music (and chances are higher once you can talk to them frequently) they will also turn into facebook fans. So I recommend switching from rootmusic which you are using right now on your facebook profile to bandRX or Songpier since both services allow you to give access to your music in return of mail adresses. Songpier is a very new service but they also offer a cool mobile app (right now also without collecting mail adresses)
Here is a video about bandRX

Filip: Question2 – What do you think of Bandcamp?
I personally think it’s a great platform for selling music and there is an option of collecting mail adresses. The downside is that there is no valuable content that can be published, like blogs. It would be perfect if it was just a music-streaming, checkout widget on my site.

Rene: One of my Favourite (but retired) bands Jester’s Funeral have just published all their songs to bandcamp and have linked to their homepage and from the homepage to bandcamp. It is not quite the widged you are asking for but I guess this stays an option especially if you don’t bring the technical know how of programming a homepage that enables you to offer your music as a download in exchange of mail adresses.
There is only one thing that bothers me about bandcamp. They only let 200 fans per month download your music for free (email exchange) and offer a pay as much as you want option. From the money raised they keep 15% as a service charge. If you want more free downloads you have to buy them or have people pay for your music.
To some extend they offer a fair deal. It is a good service for a reasonable price. I as a programmer would just do it on my own have the full controll of my data and keep the 15% but I am pretty convinced that bandcamp should be a pretty good option for many musicians
I hope I could answer your questions to your satisfaction! Sorry that there isn’t always the clear black our white, right or wrong. Things are complex on the web but by reading your mail I am very convinced that you are asking the right questions which means that at least in online marketing you are far ahead of 95% of all musicians!