Hi Andrea!
You may wish nested metadata for (at least) two reasons:
(1) support of a more sophisticated bibliographic format like MODS
http://www.loc.gov/standards/mods/
(2) need to embed description of "linked objects" (for instance,
information about each of the authors)
Case (1) may be judged (or not) out of DSpace scope: I do not intend to
make efforts in this direction (except inspiring me from MODS when
deciding to "extend" DC in a given application)
Case (2) is interesting me a lot. If you look at a DSpace instance I am
preparing (server may be down):
http://www.windmusic.org/dspace
you see at the bottom of the collections list "Authors", "Publishers", etc.
I will use those collections as "Authority lists" (in another
application I will also have "Subjects" because the thesaurus (MeSH) is
exceeding largely "Controlled Vocabulary" capacity).
This means that those collections will be used to save supplementary
data about Authors, Publishers (like if they were bibliographic
records): they will have completely different input forms and displays
than bibliographic records but each author or publisher will be an "Item".
Then the problem is to manage links within DSpace fields value. For me
there is different kink of links
(1) links to "values" (self-controlled field values): when inputing the
field, the submitter should be presented (auto-complete AJAX) a list of
existing values in the field: If really a new value is needed, it can be
typed. Elsean existing value is easy to select. DSpace Controlled
vocabulary and Input Forms Menus can also be used for this.
(2) links to a local collection: a definition associated with the field
indicates which index has to be used to search with the field content to
retrieve an item within the target collection. then the handle of the
item (or another unique identifier field) can be added to field content.
I put this handle or identifier as a suffix to the field value: [=id]
(this is what you see uninterpreted for now in current version of
windmusic application). This information will be used dynamically at
display time to generate "horizontal searches" for other records of the
same author for instance. Example at:
http://www.destin.be/dspace/handle/443803704/1292
(3) a special case is when the index used is based on an unique
identifier field (ISSN for instance): nothing has to be added to the field
(4) Finally, the encoding [=id] also allows for a weight (number of
instruments in WindMusic) and for a type of relation. For instance:
Flute[solo+2]
means "Flute" (in an "Intrumentation" field) is linking to the
Instrument identified by "Flute", there are 2 flutes and they are used
by soloists.
I will have to implement also links controlled by a foreign collection
(see my Rome poster) of a "sister" DSpace application.
I understand this may seem very different from your approach. But I
think DSpace simplicity is one of its strength and I prefer to interlink
simple (flat) objects rather than creating complex ones... I agree with
Mark that this looks like embedding RDF in DSpace (except for the weight
which is essential in my applications) but I see no immediate benefits
of RDF technology for DSpace (compared to the effort).
Wishing you a very nice week-end!
Christophe Dupriez
Andrea Bollini a écrit :
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
begin:vcard
fn:Christophe Dupriez
n:Dupriez;Christophe
org:DESTIN inc. SSEB
adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 1;Bruxelles;;B-1030;Belgique
email;internet:[EMAIL PROTECTED]
title:Informaticien
tel;work:+32/2/216.66.15
tel;fax:+32/2/242.97.25
tel;cell:+32/475.77.62.11
note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de Traitement de l'Information
x-mozilla-html:TRUE
url:http://www.destin.be
version:2.1
end:vcard
-------------------------------------------------------------------------
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
