DSpace Ambargo İşlevselliği

Ambargo

Ambargo nedir?

Bir ambargo, meta verilere veya bit akışlarına (yani dosyalar) yerleştirilen geçici bir erişim kısıtlamasıdır. Kapsamı veya süresi değişebilir, ancak zamanla sona ermesi gerçeği, onu diğer içerik kısıtlamalarından ayıran şeydir. Örneğin, DSpace için hedeflenen içeriğin lisanslı veya kullanımına dayalı kalıcı kullanım kısıtlamaları ile gelmesi olağandışı değildir. kurumsal olarak bağlı kullanıcılara erişimi sınırlayan diğer IP tabanlı gereksinimler. Bunlar gibi kısıtlamalar, tipik olarak Öğeler, Koleksiyonlar, Bit Akışları, vb. Öğelerine belirli erişim politikaları (aka "kaynak politikaları") eklenerek DSpace'deki standart yönetim araçları kullanılarak uygulanır ve yönetilir.

Ambargo işlevselliği başlangıçta DSpace 1.6'ın bir parçası olarak sunuldu ve bu, öğede yer alan tüm bit akışlarına uygulanan öğe düzeyinde ambargolar oluşturmasını sağladı. DSpace 3.0’dan bu yana, bu işlevsellik bireysel bit akışları seviyesindeki ambargoları sağlayan Gönderme Kullanıcı Arayüzüne genişletildi.

DSpace Ambargo İşlevselliği

Öğelere (meta veriler dahil) ve bit akışına (yani dosya) ambargo uygulanabilir Öğe düzeyi ambargosu her varsayılan olacaktır bit akışına en özelleştirilmiş olabilir, ancak bit akışı düzeyde.

Bir ambargo, bir öğe düzeyinde veya bir bit akışı düzeyinde ayarlanmışsa, ilgili Öğeye veya Bitstream'e yeni bir ResourcePolicy (yani erişim politikası) eklenir. Bu ResourcePolicy, ambargoyu kaldırmayı otomatik olarak kontrol eder (ambargo tarihi geçtiğinde). Bir ambargo yükseltme tarihi genellikle böyle bir politikanın "başlangıç ​​tarihi" olarak kaydedilir. Temel olarak, bu, politikada tanımlanan erişim haklarının o tarihten sonra geçerliliğini yitirmediği anlamına gelir  (ve bu tarihten önce erişim hakları yalnızca Yönetici için varsayılan olacaktır).

Zamanlanmış, manuel "ambargo kaldırıcı" komutları (DSpace 3'ten önce kullanılır) artık gerekli değildir ve çalıştırılması önerilmez.

Mevcut Öğelerdeki Ambargoları Yönetme

Yöneticiler, nesnedeki yetkilendirme politikasını (ResourcePolicy) düzenleyerek herhangi bir ambargonun yayınlanma tarihini değiştirebilir. Bu yetkilendirme politikaları, "Yetkilendirmeler" üzerine tıklayarak Öğe Düzenle ekranından yönetilebilir.

  • Bir ambargo eklemek için uygun politikayı düzenleyin ve "başlangıç ​​tarihi" ayarlayın. Tam Öğe ambargosu (meta veriler dahil) eklemek için Öğe politikasını düzenleyin. Bireysel bit akışlarını ambargo yapmak için uygun Bitstream ilkesini düzenleyin.

  • Bir ambargoyu kaldırmak için uygun politikayı düzenleyin ve "başlangıç ​​tarihini" silin.
  • Bir ambargoyu değiştirmek için uygun politikayı düzenleyin ve "başlangıç ​​tarihini" yeni bir tarihe değiştirin.

Ambargodaki değişiklikler derhal yürürlüğe girmelidir. Ancak, Yöneticiler ambargolu öğelere tam erişime sahip olduklarından, önce oturumu kapatmanız gerekebilir. Çıkış yaptıktan sonra, ambargoya maruz kalacaksınız.

DSpace Submission User Interface'ta Embargo'yu yapılandırma ve kullanma

Giriş

Aşağıdaki bölümlerde, DSpace Submission User Interface'ta Embargo işlevini yapılandırmak ve kullanmak için gereken adımlar açıklanmaktadır .

Bir DSpace yöneticisi olarak, kullanıcı arabiriminde öğe gönderme işleminin bir parçası olarak Basit veya Gelişmiş Ambargoyu entegre etmeyi seçebilirsiniz. Bunlar, Basit Ambargo Ayarları  ve  Gelişmiş Ambargo Ayarları bölümlerinde ayrıntılı olarak açıklanmıştır  .

Bu tercih dspace.cfg  değerinde  saklanır  webui.submission.restrictstep.enableAdvancedFormAyarlanmadıysa, varsayılan Basit Ambargo içindir.

Tek bir öğe düzeyinde, DSpace web arayüzüne (arama, göz atma, keşif) ve ayrıca makine arayüzlerine (REST-API) hizmet veren farklı indekslerdeki materyal meta verilerinin görünürlüğünü kontrol etmek için yeni bir Özel / Genel durum tanıtılmıştır. , OAI-PMH,…)

Embargo Kullanıcı Arayüzünü Yapılandırma

Daha önce de belirtildiği gibi, kullanıcı arasında seçim yapması için bir fırsat verilecektir:

İkisi arasında geçiş yapmak için, dspace.cfg dosyasında (veya local.cfg dosyasında aşağıdaki değişkeni ayarlamanız gerekir , bkz. Yapılandırma Referansı ). Bir false değeri (varsayılan) Basit ayarları etkinleştirirken, true değeri Gelişmiş ayarları etkinleştirir.

webui.submission.restrictstep.enableAdvancedForm=false

Yapılandırma adı değişti

Yapılandırma parametresi adının DSpace 4.0'da xmlui .submission.restrictstep.enableAdvancedForm ile webui.submission.restrictstep.enableAdvancedForm olarak değiştirildiğini lütfen unutmayın

Gönderim Süreci

madde-submission.xml

Ambargoyu etkinleştirmek için dizinde bulunan item-submission.xml dosyasında değişiklik yapılması gerekir [dspace]/config/Bu dosya, yeni bir öğenin gönderiminde hangi adımların yürütüleceğini belirler (ayrıca bkz  Kullanıcı Arayüzünün Gönderilmesi ).

Dosyaya iki yeni başvuru adımı getirildi. Varsayılan olarak, etkin değildirler:

  • AccessStep : Kullanıcının ambargoyu öğe düzeyinde ayarlayarak adım meta verisine erişimi etkili bir şekilde kısıtlaması.
  • UploadWithEmbargoStep : Kullanıcının ambargoyu bit akımı düzeyinde ayarlayabileceği adım. Bu adım etkinse, eski UploadStep devre dışı bırakılmalıdır. Her iki basamağın da açık bırakılması sistem arızasına neden olur.

İşte yeni dosyadan bir alıntı:

<!--Step 3 will be to Manage Item access.
       <step>
           <heading>submit.progressbar.access</heading>
           <processing-class>org.dspace.submit.step.AccessStep</processing-class>
           <jspui-binding>org.dspace.app.webui.submit.step.JSPAccessStep</jspui-binding>
           <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.AccessStep</xmlui-binding>
           <workflow-editable>true</workflow-editable>
       </step>
       -->
 
<!-- Step 4 Upload Item with Embargo Features (not supported in JSPUI)
            to enable this step, please make sure to comment-out the previous step "UploadStep"
       <step>
           <heading>submit.progressbar.upload</heading>
           <processing-class>org.dspace.submit.step.UploadWithEmbargoStep</processing-class>
           <jspui-binding>org.dspace.app.webui.submit.step.JSPUploadWithEmbargoStep</jspui-binding>
           <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.UploadWithEmbargoStep</xmlui-binding>
           <workflow-editable>true</workflow-editable>
       </step>
        -->

Yeni Embargo'yu etkinleştirmek için, yeni adımların yorumlanmadığından ve eski UploadStep'in yorumlandığından emin olun.

Basit Ambargo Ayarları

Basit ambargo ayarlarını kullanarak, gönderenler, tüm adsız ve varsayılan okuma erişimine uygulanan belirli tarihlere bağlı ambargoları tanımlayabilecektir. Arabirimi basit tutmak için, belirli DSpace kullanıcı grupları için ambargo uygulama seçenekleri gösterilmez. Basit ambargo ayarları arayüzü ambargoların gönderimden hemen sonra her zaman başladığını varsayar, bu nedenle sadece bitiş tarihleri ​​yapılandırılabilir.

AccessStep

Basit AccessStep Embargo formu, kullanıcı için üç seçenek sunar:

  • Özel öğe : bir öğenin meta verilerini tüm arama ve göz atma dizinlerinden ve ayrıca OAI-PMH gibi harici arabirimlerden gizlemek için.
  • Belirli Tarihlere Kadar Ambargo Erişimi : Maddenin ambargo edileceği tarihi belirtmek için.
  • Sebep : Bir öğenin ambargo altında olmasının nedenini açıklamak.

Embargo ayarlandığında, Anonim veya o belirli koleksiyon için varsayılan okuma erişimine sahip olduğu belirtilen herhangi bir Grup için geçerlidir .

Bu, basit ambargo ayarlarını kullanarak Erişim adımının nasıl oluşturulduğunu gösterir:

UploadWithEmbargoStep

Basit UploadWithEmbargoStep formu kullanıcı için iki yeni alan oluşturur:

  • Belirli Tarihe Kadar Ambargo Erişimi : bit akımının ambargolanacağı tarihe işaret etmek için Boş bırakıldığında, ambargo uygulanmaz.
  • Sebep : Bit akımının ambargo altında olmasının nedenini açıklamak .

Bu alanlar AccessStep'te ayarlanan değerlerle önceden yüklenecektir.

Aşağıdaki resimde, önceden yüklenmiş değerlere sahip basit ambargo ayarları kullanılarak oluşturulan Yükleme adımı formu gösterilmektedir:

Gelişmiş Ambargo Ayarları

Gelişmiş Embargo ayarları, DSpace'deki kullanıcı gruplarının farkında olan ve Kaynak Politikalarının nasıl çalıştığını anlayan bir akılcıyla gerçekten tasarlandı.

AccessStep

Gelişmiş AccessStep Embargo adımı, kullanıcıların öğeye eklenecek daha iyi ayarlanmış kaynak politikalarını yönetmelerini sağlar.

Form aşağıdaki alanları oluşturur:

  • Politikalar Listesi : önceden eklenmiş olan özel politikaların listesi.
  • Özel Öğe : Bir öğenin meta verilerinin tüm arama ve göz atma dizinlerinden ve ayrıca OAI-PMH gibi harici arabirimlerden gizlenip gizlenmeyeceği.
  • İsim : politikaya bir isim vermek için.
  • Gruplar : politikanın uygulanacağı kullanıcı gruplarını belirtmek için.
  • Görünür / Ambargolu : Maddenin belirli bir grup için görünür veya ambargolu olup olmayacağı.
  • Belirli Tarihlere Kadar Ambargo Erişimi : Maddenin ambargo edileceği tarihi belirtmek için.
  • Sebep : politikanın uygulanma nedenini açıklamak.

Son iki alan yalnızca Embargoed seçildiğinde etkinleştirilecektir .

Bu adım, kullanıcıya politikayı manuel olarak yönetme fırsatı verir, böylece aşağıdaki gibi kombinasyonlar mümkün olacaktır:

  • Adsız Ambargoyu Ayarla
  • Belirli bir gruba ait kullanıcılar dışında, herkes için Embargo'yu ayarlayın.
  • Embargo’yu belirli gruplar için ayarlayın, ancak diğer gruplar için değil ...

Gelişmiş ambargo ayarları için işlenecek olan Access adım formunun bir ekran görüntüsü:

UploadWithEmbargoStep

Gelişmiş Embargo ayarları için UploadWithEmbargoStep , yüklenen dosyalar listesinde Düzenle'nin yanında ek bir Politika düğmesi görüntüler Tıklamak sizi bit akışında mevcut politikaları düzenleyebileceğiniz ve yenilerini ekleyebileceğiniz bir sayfaya götürür.

Düğmeye basıldığında, AccessStep'tekine benzer bir form oluşturulacak ve böylece politikaların bit akımı seviyesinde yönetilmesi mümkün olacak .

Görüntülenen grupların listesini belirli (alt) gruplarla kısıtla

DSpace'in büyük örnekleri için, Gruplar listesi oldukça uzun olabilir. Gruplar yuvalanabilir. Bu, yalnızca EPonların gruplara üye olamayacağı, grupların kendileri diğer gruplara ait olabileceği anlamına gelir.

Gelişmiş ambargo ayarları etkinleştirildiğinde, göndericilere görüntülenen grupların listesini belirli bir grubun alt gruplarıyla sınırlayabilirsiniz.

Bu özelliği kullanmak için, dspace.cfg dosyasında aşağıdaki yapılandırma değerine süper grup adını atayın:

webui.submission.restrictstep.groups = name_of_the_supergroup

Yapılandırma adı değişti

Yapılandırma parametresi adının DSpace 4.0'da xmlui .submission.restrictstep.groups adresinden webui .submission.restrictstep.groups olarak değiştirildiğini lütfen unutmayın


Burada belirli bir grup üst grup olarak yapılandırıldığında, seçim iletişim kutularına yalnızca belirtilen gruba ait gruplar yüklenir. Varsayılan olarak, tüm gruplar yüklenir.

Özel / Genel Ürün

Bir öğenin Deposunda arşivlendikten sonra Özel / Genel durumunu ayarlamak da mümkündür.

Güncellenen Öğeyi Düzenle iletişim kutusunu gösteren bir ekran görüntüsü :

Özel öğeler, DSpace araması, göz atma veya Keşif dizinleri aracılığıyla alınamaz.

Bu nedenle, tüm özel öğelere göz atmak için yalnızca yönetici görünümü oluşturuldu. İşte bu yeni formun bir ekran görüntüsü:

3.0 Öncesi Ambargo Göçmenlik Rutini

DSpace 1.xx sürümünden yeni bir sürüm yükselttiyseniz, şu anda "etkin" olan ambargoların ResourcePolicies'e taşınması gerekir. 3.0'dan önce, DSpace'deki ambargolar tamamen meta veri alanlarında yönetildi (ve zamanlanmış bir "embargo-lifter" komutu çalıştırılması gerekiyordu). Ancak, DSpace artık tüm ambargo bilgilerini doğrudan ResourcePolicies'de (yani "erişim politikaları") depolamaktadır. Bu ResourcePolicies, ambargo tarihi geçtikten sonra otomatik olarak bir ambargoyu kaldırır.

Eski ambargoları ResourcePolicies'e geçirmek için bir göç rutini geliştirilmiştir.  Lütfen bu geçiş işleminin yalnızca bir kez çalıştırılması gerektiğine dikkat edin(derhal 1.xx sürümünden daha yeni bir DSpace sürümüne geçtikten sonra). Bu noktadan sonra, yeni tanımlanmış tüm ambargolar otomatik olarak ResourcePolicies'de depolanacaktır.

Çalıştırmak için aşağıdaki komutu çalıştırın:

[dspace]/bin/dspace migrate-embargo -a

Teknik özellikler

Giriş

Aşağıdaki bölümler , yeni Gelişmiş Embargo işlevselliğini eklemek için arka uçta yapılan teknik değişiklikleri göstermektedir .

ResourcePolicy

Bir ambargo, öğe düzeyinde veya bit akışı düzeyinde ayarlandığında, yeni bir ResourcePolicy eklenecektir.

ResourcePolicy sınıfına üç yeni özellik eklenmiştir:

  • rpname : kaynak politikası adı
  • rptype : kaynak ilkesi türü
  • rpdescription : kaynak politikası açıklaması

Rpname ve rpdescription , kullanıcılar tarafından yönetilebilen alanlar olmasına rağmen rptype , DSpace tarafından yönetilir. Aşağıdakiler arasında bir kaynak politikasının kabul edebileceği bir türü temsil eder:

  • TYPE_SUBMISSION: başvuru sürecinde otomatik olarak eklenen tüm politikalar
  • TYPE_WORKFLOW: iş akışı aşamasında otomatik olarak eklenen tüm politikalar
  • TYPE_CUSTOM: kullanıcılar tarafından eklenen tüm özel politikalar
  • TYPE_INHERITED: çevreleyen nesneden miras alınan tüm politikalar (Item için, Collection; Bitstream için, Item).

Tek bir politika kaydında yer alan tüm bilgilerin bir örneği:

policy_id: 4847
resource_type_id: 2
resource_id: 89
action_id: 0
eperson_id:
epersongroup_id: 0
start_date: 2013-01-01
end_date:
rpname: Embargo Policy
rpdescription:  Embargoed through 2012
rptype: TYPE_CUSTOM

madde

Özel / Kamu durumunu yönetmek için, Maddeye yeni bir boolean niteliği eklendi:

  • isDiscoverable

Bir Öğe özel olduğunda, özellik false değerini alır .

Item.inheritCollectionDefaultPolicies (Koleksiyon c)

Bu yöntem, kullanıcılar tarafından eklenen özel politikaları yerinde bırakmak ve yalnızca özel politika yoksa, varsayılan koleksiyon politikalarını eklemek için ayarlandı.

AuthorizeManager

Yeni alanları yönetmek için AuthorizeManager'da bazı yöntemler değiştirilmiş ve bazı kolaylık yöntemleri tanıtılmıştır:

public static List<ResourcePolicy> findPoliciesByDSOAndType(Context c, DSpaceObject o, String type);
public static void removeAllPoliciesByDSOAndTypeNotEqualsTo(Context c, DSpaceObject o, String type);
public static boolean isAnIdenticalPolicyAlreadyInPlace(Context c, DSpaceObject o, ResourcePolicy rp);
public static ResourcePolicy createOrModifyPolicy(ResourcePolicy policy, Context context, String name, int idGroup, EPerson ePerson, Date embargoDate, int action, String reason, DSpaceObject dso);

Öğe Çekme

Bir öğeyi depodan çekme özelliği, tüm özel politikaları yerinde tutmak için değiştirildi.

Eski haline getirme Öğesi

Depodaki bir öğeyi eski durumuna getirme özelliği, mevcut özel politikaları korumak için değiştirildi.

Ön DSpace 3.0 Ambargo Uyumluluğu

Ön-DSpace 3.0 ambargo işlevi (aşağıya bakınız), politika belirleyiciyi ve kaldırıcıyı ayarlamak için değiştirildi. Bu sınıflar artık, öğe meta verilerinde tarihi ayarlamaya ek olarak, ilke nesnelerinin içindeki tarihleri ​​de ayarlamaktadır.

Meta Verilerle Ambargo Oluşturma

Giriş

DSpace 3.0'dan önce, tüm DSpace ambargoları meta veri olarak depolandı. Ambargolar artık meta veri alanlarında kalıcı olarak depolanmamakla birlikte (artık ResourcePolicies'te, yani erişim politikalarında depolanmaktadır), ambargolar  yine de meta veri alanları aracılığıyla başlatılabilir.  

Ambargoları meta veri yoluyla oluşturma / başlatma yeteneği, elektronik araçlar yoluyla ( Basit Arşiv Biçimi ile Öğelerin İçe Aktarılması ,  SWORDv1 ,  SWORDv2 , vb.) Elektronik içeriğiyle ambargo içeriğini göndermek istiyorsanız çok güçlüdür  .

Embargo terimlerini meta verilerle ayarlama

İşlevsel olarak, ambargo sistemi ambargoya nasıl uygulanacağını ifade eden depoya yerleştirilmeden önce bir öğeye "terimler" eklemenizi sağlar. Burada "terimler" ile ne kastediyoruz? Gerçekten de, sistemin ambargo süresi dolduğunda (1) ve (2) somut bir erişim kısıtlamaları dizisine dönüştürebildiğine dair herhangi bir ifadedir. Bazı örnekler:

"2020-09-12" - mutlak bir tarih (yani, ambargonun kaldırılacağı tarih) 
"6 ay" - öğenin 
"sonsuza kadar" ne zaman katıldığı ile ilgili bir süre - sadece belirsiz veya açık uçlu bir ambargo 
" 2015 "- hem bir zaman, hem de istisna (halkın 2015 yılına kadar erişimi yok, yerel kullanıcılar hemen TAMAM) 
" Doğa Yayın Grubu standardı "- bir yerde bir politikaya bakıyor (genellikle 6 ay)

Bu terimler, ambargonun kaldırılabileceği (veya "kaldırılabildiği") belirli bir tarih ve belirli bir erişim politikası kümesi vermek üzere, ambargo sistemi tarafından yorumlanır. Açıkçası, bazı terimlerin yorumlanması diğerlerinden daha kolaydır (mutlak tarih gerçekten hiçbirini gerektirmez) ve varsayılan ambargo mantığı yalnızca en temel terimleri (yukarıdaki birinci ve üçüncü örnekler) anlar. Ancak aşağıda göreceğimiz gibi, ambargo sistemi, sahip olmak istediğiniz terim ifadeleriyle başa çıkabilmek için kendi tercümanlarınızı ekleyebilmenizi sağlar. Yorumun sonucu olan bu tarih öğe ile birlikte saklanır. Ambargo sistemi, o tarihin ne zaman geçtiğini algılar ve ambargoyu kaldırır ("kaldırır"), böylece öğe bit akışları kullanılabilir hale gelir. Ambargolu bir öğe için daha ayrıntılı bir yaşam döngüsü:

Şartlar atama

Bir öğeye bir ambargo yerleştirmedeki ilk adım, kendisine "terim" eklemek (atamak). Bu şartlar eksikse, ambargo uygulanmayacaktır. Aşağıda göreceğimiz gibi, terimler yapılandırılabilir bir DSpace meta veri alanında taşınır, bu nedenle terimlerin atanması yalnızca bir meta veri alanına değer atamak anlamına gelir. Bu, bir web gönderimi kullanıcı arayüzü formunda, bir SWORD depozito paketinde, toplu bir içe aktarma işleminde vb. Yapılabilir - herhangi bir yerde meta veri DSpace'e iletilir. Terimler, derhal işlem görmez ve yaşam döngüsünün bir sonraki aşamasına kadar revize edilebilir, düzeltilebilir, kaldırılabilir vb. Böylece bir teklif veren bir değer girebilir ve bir koleksiyon editörü bunun yerine geçer ve sadece son değer kullanılır. Meta veri alanları çok değerli olduğundan, teorik olarak birden fazla terim değeri olabilir, ancak varsayılan uygulamada yalnızca biri tanınır.

Terimler yorumlama / yükleme

DSpace terminolojisinde, bir Öğe herhangi bir iş akışı adımından sonuncusundan çıktığında (veya bunun için hiçbiri tanımlanmadıysa), depoya "kurulduğu" söylenir. Bu tam zamanda, terimlerin yorumlanması gerçekleşir ve hesaplanan bir "kaldırma tarihi" tayin edilir ve Maddenin Kaynak Politikası (aka politikası) 'nın bir parçası olarak kaydedilir. Kaldırma tarihi ResourcePolicy'ye atandığında, ambargoyu tanımlayan meta veri alanı  temizlenir . Bu noktadan itibaren, tüm ambargo bilgileri ResourcePolicy tarafından kontrol edilir / tanımlanır.

Bu yorumlamanın sadece bir kez yapıldığını anlamak önemlidir (tıpkı kurulum gibi). Bu nedenle, bir ambargoyu güncellemek / değiştirmek meta veri alanları üzerinden yapılamaz. Bunun yerine, tüm ambargo güncellemelerinin ResourcePolicies'a kendileri yapılması gerekir (örn. ResourcePolicies, Öğe Düzenle ekranlarındaki Yönetici Arayüzünden yönetilebilir).

Ayrıca, bu politika değişikliklerinin kurulumdan önce gerçekleştiğinden, ambargolu içeriğin "açığa çıkarıldığı" (yöneticiler tarafından erişilebilir olmayan) zamanın olmadığına dikkat edin. Birlikte yorumlama ve dayatma terimleri, ambargoyu "ayarlamak" olarak adlandırılır ve her ikisini de gerçekleştiren bileşene, ambargo "ayarlayıcı" denir.

Ambargo dönemi

Bir ambargo öğesi yüklendikten sonra, politika kısıtlamaları ambargo tarihi geçinceye kadar yürürlükte kalır. Ambargo tarihi geçtikten sonra politika kısıtlamaları otomatik olarak kaldırılır. Bir ambargo kaldırma tarihi genellikle bir politikanın "başlangıç ​​tarihi" olarak kaydedilir. Temel olarak, bu, politikanın bu tarihten sonraya kadar uygulanmadığı anlamına gelir (ve bu tarihten önce, nesne varsayılan olarak yalnızca Yönetici erişimidir).

Yöneticiler, politikayı (ResourcePolicy) düzenleyerek ambargonun yayınlanma tarihini değiştirebilir. Bu politikalar Öğe Düzenle ekranlarından yönetilebilir.

Meta veri alanlarının yapılandırılması

DSpace ambargoları, hem "terimleri" hem de "yükseltme tarihini" tutmak için standart meta veri alanlarını kullanır. Kullandığınız alanlar yapılandırılabilir ve belirli bir meta veri öğesi ambargoda kullanılmak üzere tahsis edilmemiş veya önceden tanımlanmamış. Bunun yerine, ambargo sisteminin terimleri bulması veya kaldırma tarihi tayin etmesi gerektiğinde incelemesini istediğiniz alanı tam olarak belirtmeniz gerekir.

Bu atamaları belirten özellikler dspace.cfg dosyasında bulunur:

# DC metadata field to hold the user-supplied embargo terms
embargo.field.terms = SCHEMA.ELEMENT.QUALIFIER
 
# DC metadata field to hold computed "lift date" of embargo
embargo.field.lift = SCHEMA.ELEMENT.QUALIFIER

Yer tutucu değerlerini gerçek meta veri alanı adlarıyla değiştirirsiniz. Sadece "varsayılan" ambargo davranışına (esas olarak sadece "kesin" tarihleri ​​"terimler" olarak kabul eder) ihtiyacınız varsa, aşağıda belirtilenler dışında, gereken tek yapılandırma budur.

Özel "sonsuza dek" tarihi için de bir özellik var:

# string in terms field to indicate indefinite embargo
embargo.terms.open = forever

Dilbilimsel veya diğer tercihlere uyacak şekilde değiştirebilirsiniz.

Mevcut meta veri alanlarını kullanmakta veya yeni alanlar oluşturmakta özgürsünüz. İkinci seçeneği varsa, ambargo sistemi olmadığını anlamalıdır değil aslında bunları oluşturmak için tüm standart belgelenmiş prosedürleri takip gerekir yani (meta kayıt defterine ekleyerek yani ya, vb şablonları görüntülemek için): oluşturmak veya yapılandırmak bu alanları - bu otomatik olarak gerçekleşmez. Aynı şekilde, "terimler" alanının gönderim ekranlarında ve iş akışlarında görünmesini istiyorsanız, yapılandırılabilir gönderim için belgelenmiş prosedürü izlemelisiniz (temel olarak, bu alanı input-forms.xml dosyasına eklemek anlamına gelir). Meta veri yapılandırmasının esnekliği, ambargoları belirli koleksiyonlarla kısıtlamanızın kolay olup olmadığını kolaylaştırır, çünkü yapılandırılabilir gönderim toplama başına tanımlanabilir.

Anahtar öneriler:

  1. Yerel bir meta veri şeması kullanın. Varsayılan meta veri kayıt defterinde standart Dublin Çekirdeği ile uyumluluğun kırılması, veri deponuzdan / deponuzdan veri taşınabilirliği için sorun yaratabilir.
  2. Mevcut meta veri alanlarını kullanıyorsanız, DSpace tarafından otomatik olarak yönetilenlerden kaçının. Örneğin, "date.issued" veya "date.accessioned" gibi alanlar normalde otomatik olarak atanır ve bu nedenle ambargo kullanımı için işe alınmamalıdır.
  3. Gönderim ekranlarına "asansör tarihi" alanını yerleştirmeyin. Bu, potansiyel olarak müşterileri şaşırtmaya neden olabilir çünkü doğrudan kendisine değer atayabileceklerini hissedebilirler. Yukarıdaki yaşam döngüsünde belirtildiği gibi, bu yanlıştır: kaldırma tarihi şartlara göre ambargo sistemi tarafından atanır. Herhangi bir önceden var olan değerin üzerine yazılacaktır. Ancak bir istisna için bir sonraki öneriye bakınız.
  4. Yukarıdaki yaşam döngüsü tartışmasının açıkça ortaya koyduğu gibi, terimler uygulandıktan sonra, bu alan artık ambargo sisteminde işlem göremez. Buna karşılık, "kaldırma tarihi" alanı başvuruya kadar işlem yapılamaz Bu nedenle, aynı meta veri alanını kullanmak için hem "terimler" hem de "son tarih" yapılandırmayı düşünebilirsiniz. Bu şekilde, iş akışı sırasında yalnızca şartları ve öğe yüklendikten sonra yalnızca kaldırma tarihini görürsünüz. Meta verilerin herhangi bir nedenle terimlerini korumasını istiyorsanız, bunun yerine 2 ayrı alan kullanın.

Operasyon

Terimler ve yükseltme tarihi için tanımlanan alanlar dspace.cfg içinde atandıktan ve kullanılacağı her yerde oluşturulduktan ve yapılandırıldıktan sonra, terimler alanına yalnızca veri girerek (varsayılan ayarlayıcı kullanıyorsanız tarihleri) ambargo öğelerine başlayabilirsiniz. . İş akışından çıktıklarında otomatik olarak ambargolanacaklar ve hesaplanan kaldırma tarihinin ResourcePolicy'de depolanacağı

Ambargo işlevselliğini genişletme

Ambargo sistemi varsayılan bir "yorumlayıcı / dayatma" sınıfı ("Ayarlayıcı") sağlar.

setter

Varsayılan ayarlayıcı yalnızca iki terim ifadesini tanır: "yyyy-mm-dd" sabit biçimindeki değişmez, göreli olmayan bir tarih (ISO 8601 olarak bilinir) veya açık uçlu ambargo için kullanılan özel bir dize (varsayılan yapılandırılmış bunun değeri "sonsuza kadar" dır, ancak bu dspace.cfg dosyasında "toujours", "unendlich", vb. olarak değiştirilebilir). Tarihin geçmişte olmadığına dair minimum bir akıl kontrolü gerçekleştirecek. Benzer şekilde, varsayılan ayarlayıcı, daha ayrıntılı kurallar uygulamak yerine yalnızca yukarıda belirtilen tüm okuma politikalarını kaldıracaktır (örneğin, belirli IP gruplarına erişime izin verin, gerisini reddedin). Neyse ki, setter sınıfının kendisi konfigüre edilebilir ve java ile yazılmış ve setter arayüzüne uyması koşuluyla, istediğiniz herhangi bir davranışı "takabilirsiniz". Dspace.cfg özelliği:

# implementation of embargo setter plugin - replace with local implementation if applicable
plugin.single.org.dspace.embargo.EmbargoSetter = org.dspace.embargo.DefaultEmbargoSetter

hangi ayarlayıcının kullanılacağını denetler.