[Dspace-general] Dublin Core Registry quesion: creator, contributor.author, etc.

[Tansley, Robert]

> So the question now is, when is 1.4 going to become available?  I just
> searched the tech archive and could not find an answer.  Any idea?

Hi Jose,

As you've probably noticed, DSpace doesn't really have a formally
specified release schedule now!  That's largely because the release
cycle depends on some unpredictable factors:

- How much time the committers have to put in patches, liaise with
contributors

- How many features we think we can get into the next release.  This is
a case of drawing a line in the sand somewhere -- there are always new
features we could include in the next release but each new feature added
pushes the release cycle further back.

- How long testing, bug fixing and documentation takes after a 'feature
freeze'

Right now, we're approaching a feature freeze; one last thing we (the
committers) are really hoping to get in is an improved and documented
add-on mechanism.  As soon as that's done we'll release an alpha. Once
things have stablised a bit we'll go beta, and once enough QA has been
done and documentation ready, we'll release the full version.  I'm
guessing the full release will be some time in March now, but that
depends on how much the community mucks in to help out with the testing,
bug reporting/fixing and so forth, so you can speed up the process by
getting involved in that!

 Robert TANSLEY / HP Labs / MIT Visiting Researcher
 http://www.hpl.hp.com/personal/Robert_Tansley/


> -----Original Message-----
> From: dspace-general-bounces at mit.edu 
> [mailto:dspace-general-bounces at mit.edu]
> On Behalf Of Tansley, Robert
> Sent: Friday, January 20, 2006 5:04 PM
> To: Jim Ottaviani; dspace-general at mit.edu
> Subject: Re: [Dspace-general] Dublin Core Registry quesion:
> creator,contributor.author, etc.
> 
> > Hello to the list, and particularly the folks who initially 
> > created the 
> > DC Registry for DSpace:
> > 
> > I have a Dublin Core related question: Why was "creator" 
> > (creator.null) 
> > reserved only for use by harvested metadata?
> 
> Ah, this old chestnut! :-)
> 
> The reason contributor.author is used by default is that the 
> DSpace (as
> shipped) DC profile was based on an early draft of the DC Library
> Application Profile (DC-LAP,
> http://www.dublincore.org/documents/2004/09/10/library-applica
> tion-profi
> le/) which recommended using contributor.XXX instead of 
> creator for the
> primary author.  I believe (I could be wrong) the initial reasoning
> behind this was that often, the *author* of the work (the person who
> wrote the words) might be different from the *primary creator of the
> electronic resource*, for example the PDF, the scan of the photograph
> etc.  However in later versions of the profile, usage of creator was
> brought more in line with expectations and its uses in other profiles.
> 
> We should probably fix it so that DSpace as shipped uses the 
> up-to-date
> library application profile.  For existing installations, it will be a
> little trickier to migrate/crosswalk metadata in their 
> current profiles
> to a newer version of the profile.  Many people have added their own
> extensions to the shipped DSpace profile, so writing a universal
> migration tool isn't easy -- such a tool needs to be very 
> configurable.
> 
> In any case, the situation will be better in DSpace 1.4 for a 
> number of
> reasons:
> 
> - All of the fields used in submission, search, browse and 
> item metadata
> display views will be fully configurable, so for new installations you
> are free to determine and use your own profile or the most up-to-date
> LAP, and decide which fields appear as 'author' etc.
> 
> - Descriptive metadata can now be added for any flat schema/namespace,
> and configured as described above.  Although this doesn't enable
> "structured" metadata (for which storing in XML bitstreams is 
> still the
> recommended approach), it does mean that when people have 
> extra metadata
> requirements that aren't met by DC-LAP, they can pick elements from
> other namespaces or create their own namespaces, so that non-standard
> metadata elements can be distinguished from standard DC-LAP elements.
> 
> So all we need is a volunteer to create a configurable tool 
> to crosswalk
> metadata in live installations to a more recent/standard profile!
> 
> Rob
> 
> _______________________________________________
> Dspace-general mailing list
> Dspace-general at mit.edu
> http://mailman.mit.edu/mailman/listinfo/dspace-general
> 
> 
> 
>