Hi I have been following this discussion with great interest.
Firstly I support the promotion of policies to first class objects. It brings several advantages to Fedora 1. An easy way to provide metadata about a policy (as the first class object can of course have other datastreams) 2. An easy way to replicate the logical contents of a repository Still, the current proposal falls short of my requirements. In our repository, we have the socalled "License" objects. Data objects can declare a "hasLicense" relation to such an object, and will then be subject to the policy in the license object. The license object will primarily control which user attributes are nessesary to view the contents of the data object. The 1. point above, about the metadata about the policy is expecially valid here. We want the legal formulation about the policy to be stored alongside the technical implementation. We chose this design because we needed a straightforward way to change which license a data object was released under, and because we needed a simple way to query about objects available under a given license (ie. available to a given user) The correct way, I feel, for the fedora policy design would be as follows. Declare a Repository Object, called "fedora-system:Repository" (or something) Create a number of Policy objects, containing a policy. The policies that should be active for the entire repository should then be referenced from the Repository Object. The policies that should be active for a particular object should be referenced from that object. The policies that should be active for a datastream should be referenced from the datastream's relations. Finding the relevant policies for an invocation would be easy, as they will be the ones for the datastream referenced, the object referenced and the repository. No need for the triple store to find these. If we wanted to speed this up, we could easily cache the Repository wide policies, and have some listener to update the cache upon changes to RELS-EXT in Repository. If we cache all the Policy objects, the object and datastream lookup will also be very fast. And since the entire object is parsed whenever an operation is performed on it, the information about the PIDs of the policies are readily available. Please, at least use the central object to denote global policies. Having all policy objects be automatically active for the entire repository, with no way of turning them off is a backwards-compatible disaster waiting to happen. Regards On Fri, 2010-02-12 at 08:00 +0100, Steve Bayliss wrote: > > > > Is the policy manager service used for anything > > > > other than > > > > bootstrap (and unit tests :)? (or intended to be?) > > > > > > used for - no (apart from the tests!). intended to be - it was in > > > Muradora, it's an open question as to the form of a policy > > management > > > API > > > > I see. I think this is not really in scope for this issue, > > but I'm just trying to see how this policy manager service > > fits into the big picture in relation to this task. Do we > > see "policies as fedora objects" as an end or a means? > > Potentially both - they could be seen as resources in their own rights, > perhaps part of a network of objects that includes scanned copies of > actual licences, licence expressions (ODRL, ccREL, Onix-PL, MPEG-21 REL etc) > and licence policy enforcement expressions (XACML), all related to > the resources to which they apply. > > > Externally, are the policy manager and future API to be the > > primary focal point of policy management (and representation > > as fedora objects is merely one implementation), or are > > policies as fedora objects the primary focal point, with APIs > > and managers performing a > > supporting role for manipulating the ultimately-canonical objects? I > > think my questions have been motivated by the prospect of the latter. > > I'd see this as something similar to the RELS datastreams - editable in > their own > right as datastreams, but potentially with additional API methods for > ease-of-use > such as the relationships methods we currently have. Manipulating XACML > directly could be a barrier for some folks, so methods to simplify adding > and manipulating permissions could help. > > > > > > I'd suggest they shouldn't be in a "fedora-system" namespace unless > > > they are non-editable and somehow essential to make Fedora "work". > > > Are the objects that are currently in the fedora-system namespace > > > editable? > > > > Actually, yes, they are editable ... but there is also a fair > > bit of hard-coded functionality that isn't! To confuse > > things even more, consider the policies that are in the > > "hands off" fedora-internal-use directory. I'm not sure > > which makes most sense, but I just wanted to make note that > > this could be a potential point of confusion. > > To me, if policy objects are a means, I see the namespace > > choice as unimportant. If policy objects are an end, I would > > tend to favor 'fedora-system'. That's just my (not very > > strong) opinion right now. > > Maybe one for further discussion then, I'll make sure that FCREPO-577 is > coded in such a way to allow for either situation for now. > > > > > > > > I think there's a difference here between deprecating and not yet > > > implemented within FeSL ;o) > > > > Ahh, OK. I did not know object-level policies were not > > implemented. To be honest, I've never really had to use this > > functionality myself. > > Object level policies are implemented in the sense that FeSL "understands" > XACML policies directly identifying individual resources; resources > that are members of identified collections can also be specified. > > What's not implemented is the ability to interpret policies as applying to > the > object in which the policy resides. Currently in FeSL the XACML needs to > identify the resource. > > > > A question here is whether to (continue to) standardise on a > > > datastream called POLICY for XACML policies, whether within > > existing > > > "data" objects or in stand-alone policy objects, or to make > > that more > > > flexible. > > > > There may be other options too (format URI, RELS-INT, > > something in extended content models), but I don't know if > > anything is any better than the proposed solution. > > I'm now tending towards standardising on a datastream name for simplicity, > however there is an inconsistency with the current XACML implementation if > we > went for a POLICY datastream: > > Current situation > - POLICY datastreams on Fedora objects automatically apply to the resource > containing the datastream > - other policies are stored in specific filesystem directories > > FCREPO-577 current proposal > - POLICY datastreams need to specify the resource to which they apply > - POLICY datastreams can specify any resource > - no policies in filesystem directories (other than for bootstrapping > initial policy objects) > > So there's a case for FeSL using the (reserved) POLICY datastream for some > level > of consistency, there's also a case for using a different datastream name as > there is a difference in interpretation of the XACML with respect to > resource identification. > > So people migrating to FeSL where existing POLICY datastreams are in play > would > find a change in behaviour. > > I think the subject of resource identification could be one for discussion > at > the London meeting, potentially this could include things like > - policy applies to object where POLICY datastream applies > - policy applies to members of a collection (or more generally specified > through relationships between objects) > - policy applies to objects with a specific content model > - etc ... > > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
