Scott Phillips wrote:
We wanted to expose dspace's metadata in a way that can be used by
other applications. They are nice restfull urls that are actionable
and easily predictable.
In most cases, that should be seen as a good thing.
I can see in certain situations that you wouldn't want
On Wed, Jul 9, 2008 at 8:42 AM, Gary McGath [EMAIL PROTECTED] wrote:
This still leaves the problem of other ways the metadata can be viewed.
For instance, we've disabled METS data from the OAI provider because of
the same problem. I'm considering patching InstallItem.java so that it
never
I could be wrong about this and welcome correction, but I don't think
depositor information on an item is stored anyplace but the provenance
field. (The system does know who has add/remove/change rights on the
said item, but that's not necessarily the same thing.) This means that
if you
I've always found it a bit odd about hiding the provenance metadata
on the dspace items. I think this metadata came into existence as a
weak attempt to introduce some history on the creation of the item.
Likewise I've not been very concerned about its exposure (albeit the
submitters email
Mark Diggory wrote:
Likewise I've not been very concerned about its exposure (albeit the
submitters email address embedded there) Ideally this user info in
the provenence metadata should contain obviscated email addresses
like the kind that are allowed as sha signatures in FOAF persons.
On Jul 8, 2008, at 12:35 PM, Gary McGath wrote:
Mark Diggory wrote:
Likewise I've not been very concerned about its exposure (albeit the
submitters email address embedded there) Ideally this user info in
the provenence metadata should contain obviscated email addresses
like the kind that
On Tue, 2008-07-08 at 12:43 -0400, Gary McGath wrote:
In order to prevent provenance metadata from being easily reached by
users, and to make embargoing watertight, I'd like to disable the
metadata URLs in Manakin. (I've disabled METS output in the OAI
provider for the same reason.) Since
On Jul 8, 2008, at 3:37 PM, Conal Tuohy wrote:
On Tue, 2008-07-08 at 12:43 -0400, Gary McGath wrote:
In order to prevent provenance metadata from being easily reached by
users, and to make embargoing watertight, I'd like to disable the
metadata URLs in Manakin. (I've disabled METS output in
We wanted to expose dspace's metadata in a way that can be used by
other applications. They are nice restfull urls that are actionable
and easily predictable. There are a few themes that will do client
side parsing of those urls in javascript, it opens the possibility for
other things to
restricted. In my opinion the API should return an authorization
errors for attempting to access metadata on restricted items, and then
perhaps we could set some kid of security permissions on metadata
fields either in the registry or through some dspace.cfg parameter.
One vote
Bruc,
It is being discussed in the DSpace 2.0 architecture roadmap and is
also something of a concern in the GSoC semantic web enablement project.
Cheers,
Mark
On Jul 8, 2008, at 6:17 PM, Bruc Liong wrote:
restricted. In my opinion the API should return an authorization
errors for
11 matches
Mail list logo
