Typo on Kim's email, it should have been On Mon, Jun 13, 2011 at 1:44 PM, Mark Diggory <mdigg...@atmire.com> wrote: > Srijan, > > What a great project! > > Your approach is a sensible one. However, you'll quickly encounter > that Dspace does little to support the mapping between the two Item > types and you will endup starting to consider altering the item search > and browse indexing among other parts of the system that don't do too > well with "relationships" between Items. To compensate for this I > recommend a twofold approach > > 1.) Do start to create "Album" Items, workout a set of metadata fields > that you feel are relevant for Albums such that you can capture all > the metadata about the album into one record and manage it there. > > 2.) In the short term, also "replicate" some of the relevant metadata > you want to be able to search and browse on for a specific song into > the Song Item metadata record. This will allow you to create browse > indexes for your songs that will return all songs based on name of the > album or the album author. > > Eventually DSpace will get smarter about managing rendering > relationships. We have a project in GSoC that looks to include > Semantic Authority Control into DSpace and that would be capable of > supporting the lookup up existing "Album type" Items for linking to > when submitting a song into DSpace. > https://wiki.duraspace.org/display/GSOC/GSoC+2011+-+DSpace+SKOS+Authority+Controls > > There were a few presentations at OR that explored how to customize > DSpace to support relationships between Items. Kim Shepard and Stuart > Lewis worked out some ideas for an archive of Maori Tribal Songs / > Music. I would highly recommend chatting with them about their > approach which will allow you to create views over the Album and its > Related Songs by querying Solr to join those results. > > Best Regards, > Mark > > > On Wed, Jun 8, 2011 at 11:51 PM, Srijan Deshpande <srij...@gmail.com> wrote: >> Hello, >> I'm setting up a DSpace repository for our archive of Indian Classical >> Music. I'm currently working on our metadata schema and I have some >> questions and difficulties I need help with. >> One of my basic requirements is that each song be treated as an item in >> DSpace. This is because a 'song' (a composition) is the basic tangible unit >> in this music - compositions are taught, studied, written down, exchanged, >> and performed. Invariably, a single traditional composition will have a >> number of different versions, performed by a number of artists. Students of >> music, therefore, will want to search for a traditional composition and will >> expect to find a number of versions of it. >> In this situation, I need to know how to represent albums, or recordings of >> live concerts, both of which contain a number of compositions. From my >> research (I'm no metadata expert), this is what I've come up with: >> >> I create a separate item in DSpace for each song in the album >> I also create an item for the album >> In the album-item, I use the dc.relation.haspart property to enter URIs of >> each song-item >> In each song-item, I use the dc.relation.ispartof property to enter the URI >> of the album to which the song belongs >> >> Does this sound right? >> We also have handwritten musical scores (notation) of many compositions. Is >> it correct to use the dc.relation.isformatof property to indicate a >> relationship between an recorded composition (audio file) and its musical >> notation (scanned image)? I'd have to use the dc.relation.isformatof >> property on both items right? >> --- >> Indian music is based on melodic frameworks called 'raagas'. Any composition >> in Indian Classical music is derived from one of the hundreds of raagas. >> Therefore the raaga is an important characteristic of any composition. Would >> it be appropriate to indicate this using a new qualifier for the dc.subject >> property? As in dc.subject.raaga? >> Similarly the various rhythms to which the compositions are sung are called >> taalas. Consequently, I should use dc.subject.tala, correct? Also in this >> case, I don't see myself using dc.subject without any qualifiers at all. Is >> that appropriate? >> --- >> The compositions are classified into a number of sub-genres named 'khayal', >> 'thumri', 'bhajan' and so on. Which would be more appropriate here: >> dc.coverage.genre or dc.subject.genre? Often, there are also sub-genres, so >> dc.coverage.subgenre? >> ---- >> And one of my biggest problems is: Any performance will have a number of >> artists performing together - a singer, supporting vocalists, >> instrumentalists, percussionists etc. I can list these using dc.contributor >> with marcrel qualifiers, such as dc.contributor.singer, >> dc.contributor.instrumentalist etc. But how do I indicate each contributor's >> role? How do I show which of the contributors is the singer, which is the >> percussionist and so on? >> --- >> For the languages of the compositions, most are in Dialects of the Hindi >> language. There is a standard language code for Hindi, but there are no >> codes for dialects of hindi. How should I represent these dialects? Or >> should I stick to just showing 'Hindi' as the language of the composition? >> --- >> I know that's a lot of questions to ask in one go....any responses will be >> greatly appreciated. >> For anyone who might be interested in finding out more about Indian >> Classical Music and our archive, please take a look at the attached file. >> Thanks so very much in advance! >> Srijan Deshpande >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> DSpace-tech mailing list >> DSpace-tech@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> >> > > > > -- > Mark R. Diggory > @mire - www.atmire.com > 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 > Esperantolaan 4 - Heverlee 3001 - Belgium >
-- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
