A recent pull request (https://github.com/DSpace/DSpace/pull/244) wants to add new non-DC fields to DSpace's hacked DC namespace. Meanwhile there is intent to remove all nonstandard "dc" fields to some other namespace(s). Maybe this is the time to create a new internal-use namespace, so that we don't make extra work for ourselves later.
We don't have to move any existing DSpace-specific fields into it yet,
but it would be there when ready and its existence should encourage
such movement. Nor do we have to do any of the other stuff, such as
defining immutable namespaces, yet. We just need a place to put
DSpace-specific metadata. For a minimal implementation, we only need
an internal name ("di"?) and a unique URI to identify it externally.
While we are at it, should we also define a "local" namespace that
people can use for site-specific fields? I think this ought to be
separate so that it's easy to keep out of exports, PMH, etc. fields
that have no known meaning outside the owning institution.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
