Dzieńdobry Mateusz!
In the SKOSified world, hierarchies are all around:
http://www.w3.org/2004/02/skos/
My proposal for authority control in DSpace is based on the SKOS
standard design.
DSpace is managing human targeted catalogues of simple and flat objects.
But, if fields of those objects can
Bonjour Christophe
On Thu, 2010-05-06 at 08:52 +0200, Christophe Dupriez wrote:
Dzieńdobry Mateusz!
In the SKOSified world, hierarchies are all around:
http://www.w3.org/2004/02/skos/
My proposal for authority control in DSpace is based on the SKOS
standard design.
DSpace is managing
Dear Wole,
I created a page about my Tagging add-on in the DSpace WIKI:
http://fedora-commons.org/confluence/display/DSPACE/Tagging
Do not forget to look to attachments (Add thumbnail, Attachments option).
I hope it is clear and complete for you to start-on:
the DSpace community will certainly
Hi again Mateusz!
If you want to keep more than current affiliation of the author, I see
two possible solutions:
1) You add an intermediate object to keep information about when the
author worked at a given institution and with which responsibilities.
Such a structure is too heavy to be
I have to wonder whether some of these relationships should be in a
document repository at all. It sounds like you are building a
biographical index, which has many uses beyond document retrieval.
Better, perhaps, to make it a separate service and ensure that it and
DSpace expose interfaces
On Thu, 2010-05-06 at 08:46 -0400, Mark H. Wood wrote:
I have to wonder whether some of these relationships should be in a
document repository at all. It sounds like you are building a
biographical index, which has many uses beyond document retrieval.
Well, you guess right :)
Better,
The first time around might be a trial, but if we did a quick review before
regression testing each minor release, once the first one was done, it would
probably be an easy task. Obviously it would be beneficial to the stability of
the platform considering the amount of transitive bug fixes
I have been testing with jdom 1.1 since December and jdom 1.1.1 for the last
couple of weeks with no negative side effects, but I'll look a little closer
before I get back to you. It's become more of a question now that we're
actually doing our 1.6 migration to production.
..\Wendy
Wendy
On Thu, 2010-05-06 at 12:04 +0200, Christophe Dupriez wrote:
Hi again Mateusz!
Bonsoir Christophe
If you want to keep more than current affiliation of the author, I see
two possible solutions:
1) You add an intermediate object to keep information about when the
author worked at a given
DSpace Users / Devs -
(Wasn't sure for which list this would be more appropriate, apologies
for cross-posting)
We're looking to move our repository's production DSpace instance from
the JSPUI to the XMLUI. I've been working with the Manakin interface
for a while, but have hit a bit of a
Patrick,
You are close. Yes there is another XML source that is being
rendered, It is not DRI, but METS+DIM and is used as the source for
all details about the existing Community, Collection, Item when
rendering the view.
You will find out more about this source of XML by looking at some
If you want to change where things are placed on the final page, that
is layout, and layout is handled by XSL in the Theme stage. Aspects
add substructures to a big XML structure (the DRI document) which
holds the nonstatic data that go into the page, and then the Theme
takes what it wants from
12 matches
Mail list logo
