ESciDoc Committer Meeting 2010-05-11

Date: 11.05.2010 Start time: 14:30

Location: Karlsruhe, München phone: +49-89-38602-223  VIdOc-ISDN: 08938602595

Participants MPDL: Natasa Bulatovic, Michael Franke

Participants FIZ: Dr. Michael Hoppe, Steffen Wagner, Matthias Razum, Harald Kappus

Previous committer meeting
 * ESciDoc_Committer_Meeting_2010-05-04

Next committer meetings
 * ESciDoc_Committer_Meeting_2010-06-01

=Topics=

next Meeting

 * we can run a Comitter Meeeting on 2010-05-18

version history event
 1 2007-11-15T08:36:59.484Z released valid Status changed to released for Item escidoc:ex5.    URL <premis:eventIdentifierValue>/ir/item/version-history#v1e1</premis:eventIdentifierValue> </premis:eventIdentifier> <premis:eventType>http://purl.org/escidoc/infrastructure/event-type/release</premis:eventType> <premis:eventDateTime>2007-11-15T08:36:59.484Z</premis:eventDateTime> <premis:eventDetail>Status changed to released for Item escidoc:ex5.</premis:eventDetail> <premis:linkingAgentIdentifier xlink:href="/aa/user-account/escidoc:exuser1" xlink:title="System Administrator User" xlink:type="simple"> <premis:linkingAgentIdentifierType>http://escidoc.org/identifier-types/user</premis:linkingAgentIdentifierType> <premis:linkingAgentIdentifierValue>escidoc:exuser1</premis:linkingAgentIdentifierValue> </premis:linkingAgentIdentifier> <premis:linkingObjectIdentifier> <premis:linkingObjectIdentifierType>http://escidoc.org/identifier-types/item</premis:linkingObjectIdentifierType> <premis:linkingObjectIdentifierValue>escidoc:ex5</premis:linkingObjectIdentifierValue> </premis:linkingObjectIdentifier> </premis:event> </escidocVersions:events> </escidocVersions:version>

Outcome

 * not discussed, MPDL got out of Internet :)
 * input after VidConf: see Talk:ESciDoc_Committer_Meeting_2010-05-11

create new role &issues with default filter conditions

 * how to create a new role in the core-service with a policy that does not refer to the core service resources?
 * e.g.
 * created new policy with scope

<role:scope unlimited="false"> <role:scope-def resource-type="cone-service"/> </role:scope>


 * first case: provided very dummy policy that applies to schema, however no login of any user was possible afterwards
 * after deletion of all related data users could log-in
 * second case: provided policy with action to retrieve contexts only
 * granted this role to the user
 * when filtering for items - situation is changed -> rules which apply to default user are not simply applied, they are extended and user gets much more items then actually needed
 * the user to which this role is assigned is member of 2 user groups (with no privileges at all)
 * the following query in filters is applied (note: commented out part is most probably problematic)
 * with uncommented part user gets ca.2947 items (as it only checks for existence of privilege basically)
 * with commented part user gets ca.391 items

SELECT r.id FROM list.item r WHERE ( ( (     (        (          r.id IN ( SELECT resource_id FROM list.property WHERE local_path='/properties/version/status' AND value='released' )       )      )    )  /*  OR (      ( r.id IN (         SELECT resource_id FROM list.property WHERE EXISTS ( SELECT object_id FROM aa.role_grant WHERE user_id='escidoc:102002' AND role_id='escidoc:107021' AND (             revocation_date IS NULL OR revocation_date>CURRENT_TIMESTAMP            ) AND (             object_id IS NULL OR object_id=r.id            ) )         OR r.id IN ( SELECT resource_id FROM list.property WHERE EXISTS (             SELECT object_id FROM aa.role_grant WHERE ( group_id='escidoc:107001' OR group_id='escidoc:107006' )             AND role_id='escidoc:107021' AND ( revocation_date IS NULL OR revocation_date>CURRENT_TIMESTAMP )             AND ( object_id IS NULL OR object_id=r.id             )            ) )       )      )    ) */  ) ) AND (  r.id IN ( SELECT resource_id FROM list.property WHERE local_path='/properties/context/id' AND value='escidoc:persistent3' ) ) LIMIT 1000

Outcome

 * filters not discussed
 * Role creation
 * would make sense to create roles which are also valid for external services such as CoNE
 * external services would then have to make own PDP based on the rights provided with AA Roles and privileges
 * has to be thought properly, as also grants can be made on external objects
 * initial idea: external roles (tag a role with additional property), external grants (tag a grant with additional property)

batch update of resources

 * discuss the possibilities
 * envisioned use case:
 * user browses many images and filters them e.g. by date of creation, part of the name (simple case: all images are released, therefore searchable)
 * user selects certain number of images e.g. 500 and wants to add them metadata "place=Paris"
 * quick update of images is there ...

outcome

 * Would be good to provide use cases and scenarios
 * Input after VidConf: Imeji

others

 * eSciDoc-Colab Page setup
 * Alignment of tools and processes (e.g., Maven)
 * Improved and harmonized communication of eSciDoc
 * eSciDoc Blog
 * service names and classification
 * documentation of services
 * installation guides
 * eSciDoc Lab: Colab page gathering experimental modules
 * Exchange of staff members for specific developments or share development