[
https://jira.duraspace.org/browse/DS-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18687#action_18687
]
Tim Donohue commented on DS-668:
--------------------------------
This was discussed in Developer meeting on Jan 19, 2011.
Some disagreement over whether or not this is a good idea. Though in the end,
it seemed like several were in favor of "sane defaults", but keeping embargo
disabled by default. This may mean we will need to start a new 'dspace' schema
for these non-QDC fields (e.g. 'dspace.embargo.terms', 'dspace.embargo.lift')
This issue needs a volunteer to investigate and provide implementation
suggestions.
Full discussion follows:
[20:17] <tdonohue> Pre-configure DSpace Embargo settings so that it is easier
to enable. : https://jira.duraspace.org/browse/DS-668
[20:18] <mdiggory> just please do not create a field called dc.embargo !
[20:18] <tdonohue> DS-668 is me being frustrated with the number of questions
about configuring embargo that we had on listservs immediately after it was
released -- would appreciate others reactions to this...
[20:18] <richardrodgers> I'm not crazy about this - perconfiguration means we
have to pick a setter, and there are already 2
[20:18] <mhwood> Yes, if we put real configuration values there, they need a
namespace in which to live.
[20:19] <jefftrimble> there is no embargo element in the official DCMI terms
[20:19] <mdiggory> jefftrimble: precisely
[20:19] <tdonohue> yea, this is an area where we start to delve into whether a
'dim' schema is needed: e.g. "dim.embargo.*"
[20:19] <mdiggory> reminds me of Rob Tansleys last plea to both adding new
elements to the dc namespace
[20:19] <mhwood> IIRC we need a namespace of our own anyway -- we ship with a
few non-DC terms.
[20:20] <mdiggory> not dim
[20:20] <jefftrimble> Well, the whole defaul QDC in Dspace is so out of date
from DCMI
[20:20] <mdiggory> http://dspace.org/system or something like that
[20:21] <tdonohue> well, yea, that could be the schema path -- but it would
still need a 'short abbreviation' version. 'dim' or 'sys' or 'dsp' or whatever
[20:21] <mhwood> When I was playing with embargo, I think I made up DSpace
Supplementary Metadata: dsm
[20:21] <mdiggory> dim is not a metadata namespace, is an xml format without a
formal schema
[20:21] <mdiggory> ds
[20:21] <tdonohue> mdiggory -- good point. to avoid confusion we should *not*
use dim
[20:21] <tdonohue> ds or 'dsm' would work
[20:21] <mdiggory> we use multiple separate namespaces for workflow and
submission etc in @mire
[20:22] <tdonohue> But, getting back to the question at hand. do we like this
idea? Should we create a new namespace called 'ds' or 'dsm' and preconfigure
embargo fields? Or is this a bad idea?
[20:22] <grahamtriggs> ds is too close to dc - easy to get confused. What's
wrong with the full 'dspace'
[20:22] <mdiggory> we limit access to these when non-admins are accessing the UI
[20:23] <mdiggory> this allows us to use them for "Item State" etc when
customizing our workflows
[20:23] <tdonohue> grahamtriggs -- we could do the full 'dspace'. I have no
strong feelings any which way, we'd just need to decide on something and go
with it.
[20:23] <mhwood> I do like some form of the idea. This is one of those things
which benefit from real examples. There is a lot left open (properly, for
flexibility) and it's hard to pin it all down.
[20:24] <jefftrimble> graham's idea has lots of merit. we have too many
acronyms...
[20:24] <sandsfish> +1 for dspace
[20:24] <mhwood> 'dspace' ok with me.
[20:24] <jefftrimble> +1
[20:24] <tdonohue> +1 ok with me as well
[20:24] <richardrodgers> I'm +1 for non-dc, but against re-configuraiton
[20:24] <mdiggory> supercalfragalisticexpialadocious
[20:24] <richardrodgers> pre-configuration
[20:24] <robint> From the prism schema - prism:embargoDate.
[20:25] <mdiggory> we should probibly have prism in there already... but
without "qualifiers"
[20:26] <tdonohue> richardrodgers: why? also by "pre-configuration" I don't
mean that it should be auto-enabled. Rather, it should be easier to enable
[20:26] <mhwood> Sounds like importing 'prism' is its own improvement request.
[20:26] <mdiggory> quite true
[20:26] <jefftrimble> if you need an embargo field, your closest standard to
DCMI would but description.embargoterm and descriptoin.embargolift
[20:27] <jefftrimble> but=be something like
[20:27] <mdiggory> We've used description.embargoterm and date.embargolift
[20:27] <richardrodgers> tdonohue: you need to choose whether to have separate
terms & lift fields, what the setter and lifter are, etc and all these are
selectable. What are your grounds for choosing a default configuration?
[20:28] <mdiggory> because lift is a date and term is a description of the
embargo period
[20:28] <jefftrimble> mdiggory: that's what I meant.
[20:28] <mdiggory> :-)
[20:28] <mhwood> I think you just stated the grounds. Everything is wide open.
There are so many choices to make, it's hard to grasp how they fit together.
[20:29] <sandsfish> Is it a configuration issue or a documentation issue?
[20:29] <tdonohue> richardrodgers: I guess my grounds were more like -- it
seems too complex, if people are asking a ton of questions. I'd rather they be
able to "flip a switch" for an easy way to enable it. But, if they wanted they
are also welcome to fully tweak all options
[20:29] <richardrodgers> gotta run, I'm sorry - but Sands will report on 1.8 etc
[20:29] * richardrodgers ([email protected]) Quit
(Quit: richardrodgers)
[20:29] * PeterDietz ([email protected]) has joined #duraspace
[20:29] <tdonohue> sandsfish -- I guess it could be a docs issue as well.
[20:29] <jefftrimble> Well the dspace.cfg should have the QDC fields already
filled out....
[20:30] <mdiggory> I think sane defaults are reasonable, ultimate configuration
results ultimately in unpredictability
[20:30] <jefftrimble> so, if you go with mdiggory's suggestion, and add those
two fields to the Schema, then its a slam dunk whether or not to comment it out
or not.
[20:30] <tdonohue> +1 for sane defaults
[20:31] <robint> +1
[20:31] <snail> this seems like maybe the kind of issue that fedora might have
a policy / approach on hat we can shamelessly steal?
[20:31] <snail> s/hat/that/
[20:32] <tdonohue> OK. We're at a 1/2 hour. It sounds like we still have
differing viewpoints. If anyone is interesting in proposing a way to resolve
this (better docs, sane defaults, both), please feel free to claim this task.
We can revisit later once we have some better details in place
[20:32] <mhwood> Hmmm, maybe the concrete examples belong in the documentation.
One could argue that there is *too much* in the shipping config.
[20:32] <sandsfish> +0, sane defaults sound reasonable, though I'm not familiar
enough with the configuration to vote, but certainly if there are defaults, it
should be off by default. a HOWTO seems like it's in order in any case.
[20:33] <tdonohue> sandsfish -- agreed, +1 to 'sane defaults', but i'm also +1
to it being "off" by default. I think there's a way to fill out the base
configs with some sane defaults, while also requiring some sort of basic action
(e.g. uncommenting) to actually enable embargo
[20:34] <tdonohue> Ok -- we'll stop there for now. Add more
comments/suggestions to DS-668
[20:34] <jefftrimble> +1 for tdonohue's idea.
> Pre-configure DSpace Embargo settings so that it is easier to enable.
> ---------------------------------------------------------------------
>
> Key: DS-668
> URL: https://jira.duraspace.org/browse/DS-668
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.6.0, 1.6.1, 1.6.2
> Reporter: Tim Donohue
> Priority: Major
> Fix For: 1.8.0
>
>
> From various discussions on 'dspace-tech', there seems to be confusion on how
> to enable / setup embargo settings. There's too many steps involved, and we
> need to simplify it for less-technical folks.
> I propose we do the following:
> (1) Pre-configure all the "#### Embargo Settings ####" in dspace.cfg. So,
> actually ship DSpace with precreated 'terms' and 'lift' fields, which are
> pre-configured in dspace.cfg
> (2) Pre-configure input-forms.xml with commented-out fields which can be used
> to enable embargo. Add a comment to that file that those field(s) need to
> be uncommented to fully enable embargo functionality.
> After that, we'll just document that people just need to uncomment the
> embargo fields in 'input-forms.xml' in order to enable Embargo.
> Thoughts? Volunteers to implement?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
