Dear Mark,
Thanks! Yes this is quite a project and a very challenging one at that!
Will I really have to modify the search and browse indexing extensively? The
way I had imagined this would work was: I would make relation.haspart (for the
album-items) and relation.ispartof (for the song items) indexable and that
would be it - that would pretty much serve my purpose, right? So if a user
comes across a song that is part of an album, that fact would be shown to him
(I'd have to customize the way the relation.ispartof field is displayed) and
he'd be able to visit the album's page (since the value of the
relation.ispartof field could be the URI of the album). Also, vice versa, if
the user visits an album's listing, each of the component tracks could be
listed using relation.haspart - the values of which would be the individual
songs' URIs. This should work, right?
The SKoS authority control looks fantastic and I can imagine how incredibly
useful it would be for a project like ours! Looking forward to it.
I've actually spoken to Kim Shepherd about his work and he has promised to send
me some stuff describing his ideas, which I'm really looking forward to.
Thanks again!
-Srijan
--
Srijan Deshpande
http://be.net/ontheweb
Sent with Sparrow (http://www.sparrowmailapp.com)
On Tuesday 14 June 2011 at 12:15 AM, Mark Diggory wrote:
> Typo on Kim's email, it should have been
>
> On Mon, Jun 13, 2011 at 1:44 PM, Mark Diggory <mdigg...@atmire.com
> (mailto: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
> > (mailto: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
> > > (mailto:DSpace-tech@lists.sourceforge.net)
> > > https://lists.sourceforge.net/lists/listinfo/dspace-tech
> >
> >
> >
> > --
> > Mark R. Diggory
> > @mire - www.atmire.com (http://www.atmire.com)
> > 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
> > Esperantolaan 4 - Heverlee 3001 - Belgium
>
>
>
> --
> Mark R. Diggory
> @mire - www.atmire.com (http://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
