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
