On Monday, June 13, 2011, Srijan Deshpande <[log in to unmask]> wrote:
>
>
> 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,
Only if you want to control what thes search results include or do not
include when you are searching. For instance do you want to return the
album item if there is a match on a metadata term in one of the songs.
But if that is not an interest or concern then no, using the existing
indexer capabilities would suffice. The relationship would be viewable
without much alteration of the indexing logic. but it would be a
string (uri) that would be indexed and, for instance, if your were to
try to search on terms that may be in the album title, you wouldn't
get songs that are part of that album. (But yes, you could open the
album item and still navigate to the related songs.)
> 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.
The basic logic to visualize the relationship would be done at the
theming level, and involve just using the uri in the metadata field to
lookup the related item using a document() xslt function call to load
that document and extract it's details for presentation, you can do
this in your ItemView, and in your search and browse views.
Cheers,
Mark
> Thanks again!-Srijan
>
>
>
>
>
> --
> Srijan Deshpandehttp://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 <[log in to unmask]> 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 <[log in to unmask]> 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',
>
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
|