FCREPO-577 aims to represent, as Fedora objects, the same policies currently stored and managed by DBXML and applied against the repository and its objects. Either a decorator or observer persists changes to the policy objects to DBXML.
The determination of which policies apply to the repository/collections/objects/datastreams remains unchanged: there's no change from the PDP's perspective, so the very same policies would continue to apply as they did previously. I'm not pushing back at all on the idea of a repository object and using RELS-EXT/INT for declaring which policies are applicable--but I do believe that that describes logically different parcels of work from what's scoped by FCREPO-577. On 12 Feb 2010, at 5:54 PM, Asger Askov Blekinge wrote: > Hi > > On Fri, 2010-02-12 at 17:19 +0100, Edwin Shin wrote: >> I definitely support the proposal to have an object that represents the >> repository itself (just as I would like to see objects that represent >> fedora.fcfg, users, groups, etc.). Even before FeSL, we'd discussed the >> desirability of representing policies as Fedora objects (in contrast to the >> set of policy files stored on the filesystem in FEDORA_HOME. However, we >> should make clear that it's not a requirement/dependency for FCREPO-577. >> >> Similarly, I prefer we that we not conflate the issue of improving how >> policies are applied to datastreams, objects, the repository, etc. with >> simply getting our policies represented in the repository itself. Again, I >> very much want to see something along the lines of RELS-EXT/INT declarations >> to indicate applicable policies, but it's not a requirement of FCREPO-577. >> >> In the meantime I've created FCREPO-636 and FCREPO-637 to track these issues. >> > I am not totally in agreement. > In order to solve FC-577 we need a good way of designating which objects > are to be regarded as repository-wide policies. And because of that, > there will be some overlap. We could use some solution like all objects > with a pid that is matched by a certain reg-exp, but this has all kinds > of problems. > > By adding a Repository object we solve a number of issues, and we do not > need to support anything more than the policies to begin with. > > As object and datastream policies goes, yes, these are a separate issue, > but repository policies are not. > > Regards > > >> On 12 Feb 2010, at 1:50 PM, Asger Askov Blekinge wrote: >> >>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
