> > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
