Example applications (see also):

For unknown bands, an idea was to relate them to you in terms of bands you already know/like (in addition to manually clicking on maybe a “Like” button a la Facebook, it could be assumed that you know of bands that’ve played shows you attended, for instance), using the “six degrees of separation” mechanism like Music Routes.

A caveat with all this is that new bands formed by “nobodies” would be at a disadvantage for discovery on this system - less links on the graph - and would still need to be discovered the old-fashioned way.

Proposed structure

Relationships between musicians, bands:

I was thinking it might be necessary to reify the relationships between band members and bands, to have additional triples say things about that relationship (i.e. durations, instrument(s) played).

Example: Rather than just saying “Melissa plays in Order of the Gash”, the relationship could be expressed a bit richer (albiet more complicated) as:

Melissa has a stint;
 where that stint is in Order of the Gash,
 playing guitar,
 started 2004,
 ended Doomsday.

In Turtle syntax, this might look like:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix mo: <http://purl.org/ontology/mo/mit#> .
@prefix : <http://example.org/scene> .
<people/melissa> a foaf:Person ;
    :performs [
        a :Stint ;
        :in <bands/ootg> ;
        :plays mo:Electric_Guitar ;
        :started "2004"
    ] .

(Using relative URI’s for resources, the FOAF and Music Ontology where possibly appropriate, and a blank prefix for my own predicates. Lines like “a foaf:Person” and “a :Stint” aren’t necessary, they just add typing information for a schema and/or reasoner, in the form of additional triples on that subject, that expand out into: “http://example.org/people/melissa rdfs:type foaf:Person”)

Is there a better name to describe that relationship than “stint”? Although a name isn’t really that necessary; a blank node (a node without a URI identifier) was used as the object in the example above. Appropriate predicates might already be in the Music Ontology, or ones that could be subclassed appropriately.

Architecture

Intelligent / Heavy client:
  • AJAX queries to autocomplete when associating with existing objects, a la associate venue with event on Calagator.
  • When object doesn’t exist, client should be able to create minimal instance of that object, and use HTTP PUT in a restful fashion to persist that object on the server.

Mulgara can take simple HTTP POST to create new resource EX: http://mulgara.org/pipermail/mulgara-general/2009-September/000925.html