Embargo predicates

[bcail]

Should embargo/lease predicates be added to PCDM? See initial discussion at https://groups.google.com/forum/#!topic/pcdm/d1W6IeqbLfM. If embargo predicates are added, it might be useful to add examples to the wiki for how to use the rights extension and the new embargo predicates.

[escowles]

I think this would be a good thing to add as a PCDM extension, either adding to the existing Rights vocab (http://pcdm.org/rights#) or as a separate Access extension vocab.

[bryjbrown]

Based off my experience with Islandora 1.x's embargo system and dealing with FSU's Graduate School in handling embargo requirements/management for ETDs, these are the details of embargoes that end up mattering the most:

Object vs File

In Fedora 3 this was implemented on a PID vs datastream level, but in F4/PCDM this would be phrased in terms of embargoing the parent object vs a child file (or perhaps fileset). The thing that is embargoed is inaccessible to non-admin users, so an embargoed object would not show up in search/browse interfaces at all, it would be effectively invisible to users. An embargoed file would have the parent object show up in browse/search interfaces, but the child file would not (also consider that the parent object's display might also have a display message about one of its child files being embargoed).

It seems like the best practice in the ScholComm/IR world is to use file embargoes so that users can see that an object exists, they just can't read/download it. There aren't many situations where an object embargo is useful, but they def. do come up. Perhaps an ETD contains offensive content or falsified data, so you don't want it to be accessible yet you are still obligated to preserve it.

IP ranges

An embargo should be configurable to be either global (applies to everyone) or ranged (users on a specified IP range bypass the embargo). Ranged embargoes occur most frequently for ETDs on our campus, but some non-IR objects end up getting ranged embargoes due to licensing restrictions that say it must only be available on-campus. These ranged embargoes can be bypassed off campus as well using something like EZProxy, but it still requires users to log in with a university ID, so these ranged embargoes also end up doubling as a way to restrict any users who aren't affiliated with your university.

Expiration

An embargo should be configurable to either automatically lift at a specified date, or to stay active until manually lifted by an admin. In Islandora 1.x, expiration dates can either be a W3CDTF or the string "indefinite" but there's probably a better way to handle this.

"Stacking"

There should be a way to "stack" embargoes on an object/file so that one embargo policy can expire into another. For instance, its a very common practice here at FSU for our Grad School to say that an ETD should have its PDF globally embargoed for 2 years, and then the PDF should be on-campus access only indefinitely after that. We implement this by placing 2 different embargoes on it (the global inaccessibility overrides the on-campus access while the first embargo is active), and when the global embargo expires, it leaves the on-campus embargo active. Wearing my linked data hat, I'm inclined to believe that having two separate embargoes on an object/file seems semantically valid, and that the application should be able to apply them simultaneously with the more restrictive policy elements overriding the more permissive ones.

[bcail]

@duraspace/pdcm-committers - any more comments before we work on a PR?

[ruebot]

I think it would be good if somebody can investigate any overlap here with use cases.

[bcail]

Thanks, @ruebot. I do see "embargo" there: http://www.sparontologies.net/ontologies/pso/source.html#d4e645. Maybe it would better to use that ontology rather than add something to PCDM? If so, it'd be nice to list it as the preferred ontology for embargoes.

[ruebot]

@bcail exactly! It would be great if a couple people would be willing to do a survey of available ontologies, identify possible predicates that would be used and create recommendations, and identify where the gaps are, which should inform a path forward for extending PCDM.

[bcail]

I've started a document with some different ontologies: https://docs.google.com/document/d/1v8ZOUNM679iOjjRiIFHqQQykhPMyEXJ8MHlFJEVIw2s/edit?usp=sharing. Anyone is welcome to contribute.

[bryjbrown]

@bcali That doc is great, lots of good info there. It looks like there are many ways to say that something is embargoed, but not a lot of options for expressing how it is embargoed (policy details) that an application could make use of. For instance it looks like pso:embargoed acts as a value for pso:PublicationStatus, but nothing about when the embargo will expire. Hydra ACL looks like it comes the closest to meeting my personal requirements, but still not quite granular enough.

[bryjbrown]

If an embargo policy could be a resource itself, or more specifically an rdfs:Class like pcdm:Object/File/Collection, then a pcdm:Object or pcdm:File could link to a pcdm:Embargo URI (which would take care of the object vs. file feature mentioned above) and that embargo URI could have attributes attached like an expiration date or IP range, as well as more potential attributes that may be need like a display message or contact email.

[escowles]

I'm skeptical of making embargoes their own resources. That would be useful for handling multiple embargoes, but in most of the cases of multiple embargoes that I've heard (including the stacking comment above), I think one is an embargo, but the permanent campus-only status is the base rights/access status, not an embargo.

I would be more in favor of articulating the properties that apply to the embargo and seeing if we can attach them directly to the primary resource.

[bcail]

This issue is on the agenda for the January PCDM call (thanks Bryan).

[bcail]

@bryjbrown regarding the PSO ontology, it does have information about when an embargo will expire. You can use pso:holdsStatusInTime to specify various statuses the item will have (one of which can be pso:embargoed), and specify the time interval for that status, as well as an event that moves an item from one status to another. See https://semanticpublishing.wordpress.com/2013/03/01/lld5-using-spar-ontologies/ - search for "holdsStatusInTime".

[bryjbrown]

@bcail Interesting, here's the diagram in that page:

It looks like a document has the predicate pso:holdsStatusInTime with the object pso:StatusInTime, and that pso:StatusInTime can have lots of properties attached, such as ti:hasIntervalStartDate and ti:hasIntervalEndDate. If we could find a predicate that roughly translates to "is visible to this IP range" that takes an IP range (or something else to denote "all" or "none"), it could be attached to the pso:StatusInTime to show that this status comes with extra restrictions. This would solve the "stacking" problem I mentioned earlier as well by being able to attach different IP restrictions to different statuses.

What ontologies could we look at for specifying IP range accessibility?

[DiegoPino]

@bryjbrown looks to me that IP range /IP based embargo could be more an application or implementation concern/or even AuthZ via WebAC than something you would like to keep with your RDF properties, at least if thinking about doing it at the document level. Maybe use some type of ACL (webAC) tied to a specific IP range dealing app? Since even if you put IP's in the RDF itself, using, some kind of predicates, you still need to handle the restrictions (RW) via logic. And what if you need to change ranges or make it modal or open to a specific new network? Just my 2Cents

[DiegoPino]

@bryjbrown also: http://www.openlinksw.com/ontology/restrictions and some example with IP restriction predicates oplacl:IPAddressConditionetc with examples coming from virtuoso https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VAL_HttpRestrictions that could help with dealing with restriction definition. This is meant to define network - agent restriction, so i would assume some inter-linking through maybe user/groups or even organic groups to do so (my eyes on the pso:Agent probably)