Andrea, when I imagine "nested metadata", its attached at each level  
of the model, to express it in the database, each attached metadata  
field is still flat and an additional record in the table, there then  
needs to be the following added columns

1.) an "object id" of the parent object the metadata is attached to
2.) and an "id" of the parent metadata field it may be "related to"

It actually ends up looking alot like what called an rdf quad  
(context, subject, predicate, object).

cheers,
Mark

On Nov 21, 2007, at 7:54 AM, Andrea Bollini wrote:

> Hi all,
> at CILEA we are starting to think about "a light" support for nested
> metadata in dspace 1.5 (waiting for 2.0) and authority files.
>
> About nested metadata we have two different ideas:
> 1) use the place column in metadatavalue to keep a sync from different
> metadata i.e. to manage author affiliation we have
> contributor.author = SurnameX, NameX -> place 1
> contributor.author = SurnameY, NameY -> place 2
> contributor.affiliation = AffiliationZ -> place 1
> contributor.affiliation = AffiliationW -> place 2
> so using place 1 we can say SurnameX, NameX works for AffiliationZ at
> the time of item submission...
> with this approach we can use 1 level of nesting but only if nested
> values are not repeatable (1 affiliation for author)
>
> 2) save in the metadata value a structured xml like:
> <name />
> <surname />
> <affiliation />
> <email />
> this approach is more flexible because with it we can use more then 1
> nested level also with repeatable value...
> at DSUG Rome I have talked fastly with @mire developer (should be read
> the list) and I think
> that they are using this approach, I am right? what kind of problems
> may arise? do you think that is a sharable solution?
> The problems that we see are:
> - browse system: solvable implementing BrowseOrderDelegate
> - search system: partially solvable implementing a custom Analyzer
> - display: in jspui we need to rewrite heavy itemtag (with manakin, do
> you know if we can use directly the nested xml in DIM?)
> - oai-pmh: solvable implementing new Crosswalk
> - submission: we don't need to implement anything because data are
> loaded from an external system (see also the authority file belove)
>
> what do you think about? what is in your opinion the simplest
> solution shareable within the community and to keep forward to new
> versions?
>
> About authority files we think to move in this way:
> - use an interface IControlledValue with  getStoredValue();  getUID();
> getNote() - html text for help with ambiguous choices (like namesake &
> so) - all returning String
> - use an interface IAuthorityFilesService with List<IControlledValue>
> getControlledValuesBy(String query); IControlledValue
> getControlledValueByUID(String uid);
> - input-forms should allow to select different authority providers for
> different metadata
> - the name of the provider specified in input-form could be used to
> select the right class implementation of IAuthorityFilesService as
> NamedPlugin
> - in the metadata we want save <controlled-value
> id="ID">StoredValue</controlled-value>
> Clearly, we have to take care of the same problems of the previous  
> point
> 2 about nested metadata (browsing, search, display, oai-pmh)
>
> Best,
> Andrea
>
> -- 
> Dott. Andrea Bollini
> Responsabile tecnico sviluppo e formazione applicativi JAVA
> Sezione Servizi per le Biblioteche e l'Editoria Elettronica
> CILEA, http://www.cilea.it
> tel. +39 06-59292831  cel. +39 348-8277525
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dspace-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to