ESciDoc Developer Workshop 2007-12-19

Date: December 19-20, 2007
Location: FIZ, Karlsruhe
Participants(MPDL): Michael, Robert, Johannes, Tobias, Natasa

Topics[edit]

XML Schemas[edit]

Consolidation of schemas for framework objects: the common elements in properties of framework resources should really be common, i.e. in the same namespace across resources; no more item:created-by, ou:created-by, ... but only escidoc:created-by. I also have a feeling that if this is not happening soon, it never will. -Robert 11:41, 14 November 2007 (CET)

Update of last workshop results[edit]

Update of last workshop, see also ESciDoc Workshop 2007-09-24, ESciDoc Developer Workshop 2007-08-07
eSciDoc Brainstorming results
TOC in Container: format, restrictions, occurrence (see also ESciDoc_Container_Toc)
Authority Files, see also (ControlledVocab, Talk:ControlledVocab#Prototyping)
Workflow Manager, see also ESciDoc_Workflows
Item lists - prototype, results, see also ESciDoc_Item_List
- Item lists - sorting order, see requirements for Search Topic below.

Authorization[edit]

Authorization, see also ESciDoc_Authorization_Authentication and related pages
- concept how to map solution actions to core services actions
- how to enable trust if the solution already authorized the action of a user
- how to easily create new policies/modify existing policies

Relations[edit]

Providing content relations together with the item or better standalone and use addContentRelations, removeContentRelations methods.
see concept at Content relations

PID[edit]

Proposal to move the topic to the next eSciDoc workshop Jan/Feb 2008--Natasa 10:55, 7 December 2007 (CET)

In my opinion PID handling is very importent. Especially because we have a (inconsistent) implementation. In consequence i would propose to remove the PID assignment methods till we have the implementation of an agreed concept. Frank 12:09, 7 December 2007 (CET)

finalize concept for PID-Impelementation in eSciDoc
There is a Talk Talk:PubMan PID related to that topic but no concept.

the concept already exists for PID and is agreed between us previously. This concept paper was discussed before. On the Talk page there is also a proposal how to deal with PIDs so please take a look at the

http://colab.mpdl.mpg.de/mediawiki/Talk:PubMan_PID#Issue_316:_feedback and http://colab.mpdl.mpg.de/mediawiki/Talk:PubMan_PID#ObjectPIDs_and_VersionPIDs

Release procedures and Data migration[edit]

Release procedures (releases, release tests)
decide on strategy for data migration (when XSDs are changed)
- migrate each object on retrieve
- migrate all objects of the repository at the time the new release is installed via XSLT
- create a treansformation service for the migration of objects (on demand or the compelte repository)

AdminDescriptor[edit]

define content
define usage of AdminDescriptor in Context and Container See page AdminDescriptor

Statistics[edit]

Status of Statistics
- possible to gather the current statistics also with additional info on logged-in (anonymous) users?
- no need for concept. http://www.escidoc-project.de/issueManagement/show_bug.cgi?id=347 in Bugzilla is fixed and will not be reopened
- the requirement is to "rework" the definitions and the reports to also provide statisctis for all users and only for registered (i.e. logged-in users)

Content Model[edit]

Colab pages started Content Models, in progress

Enhancements for upcoming releases[edit]

Searching service[edit]

mixture of language specific metadata indexes into a one search database
- this requirement needs to be discussed together. The main issue in here is that we do have the following examples for searching:
  - search all items where title in german is "wissenschaft" and abstract in english contains "science information" - the results should be found with proper stemming options - that would mean that the exact "phrase" search through current escidoc_all database will not give back a correct set of results.

sorting order (p and P are sorted within each other -> case insensitive, german umlaute seem to be handled, as if they where ue, oe, ae, characters like [ are listed before A/a.).
- this requirement simply states that there is a case insensitive sorting order and that we have to treat german umlaute in the following manner when indexing for sorting (ä/Ä should be treated as ae, ö/Ö should be treated as oe etc.)

Context handler[edit]

additional methods, improvement of existing methods (admin descriptors, possibility to add new context types e.g. CitationStyles, Validation)--Natasa 17:08, 16 November 2007 (CET)Clarified partly: Context types are not limited.
revisit Admin descriptor (what is relevant and what not in the current admin descriptor structure)

see description on page Context handler

OrganizationalUnits handler[edit]

additional methods, improvement of existing methods
- additional filter criteria user, role, public-status.
decision on the content of OrganizationalUnit is needed - Frank

Frank, can you provide short info what do you think with this, so we prepare smth in advance?

Clarified - MPDL will provide some more info, this is only refering to the organization-details section!--Natasa 11:54, 19 November 2007 (CET)

This may pertain the properties too if in the details is some candidate for a filter or a value that occures in both properties and details. Frank 15:21, 6 December 2007 (CET)

Current organization-details structure:

   <xs:element name="organization-details">
       <xs:element name="abbreviation" type="xs:normalizedString">
       <xs:element name="name" type="xs:normalizedString">
       <xs:element name="uri" type="xs:token" minOccurs="0">
       <xs:element name="organization-type" type="xs:normalizedString" minOccurs="0">
       <xs:element name="description" type="xs:string" minOccurs="0">
       <xs:element name="external-id" type="xs:token" minOccurs="0">
       <xs:element name="postcode" type="xs:normalizedString" minOccurs="0">
       <xs:element name="country" type="xs:normalizedString" minOccurs="0">
       <xs:element name="region" type="xs:normalizedString" minOccurs="0">
       <xs:element name="address" type="xs:string" minOccurs="0">
       <xs:element name="city" type="xs:normalizedString" minOccurs="0">
       <xs:element name="telephone" type="xs:normalizedString" minOccurs="0">
       <xs:element name="fax" type="xs:normalizedString" minOccurs="0">
       <xs:element name="email" type="xs:token" minOccurs="0">
       <xs:element name="geo-coordinate" minOccurs="0">
           <xs:element name="location-longitude" type="xs:token">
           <xs:element name="location-latitude" type="xs:token">
       </xs:element> 
   </xs:element>

Should be (note: inclusion of language flags via dc: elements referenced and dc:simpleLiteral type reference):

   <xs:element name="organization-details">
       <xs:element ref="dc:title">
       <xs:element ref="dc:alternative" minOccurs=0>
       <xs:element ref="dc:identifier" type="xs:token" minOccurs="0"> (MPDL should provide clarification until the WS if we need identifier type in addition)
       <xs:element name="organization-type" type="dc:simpleLiteral" minOccurs="0">
       <xs:element name="description" type="dc:simpleLiteral" minOccurs="0"> (maybe to use dc:subject??? MPDL will check)
       <xs:element name="country" type="dc:simpleLiteral"> (should include language flag)
       <xs:element name="city" type="dc:simpleLiteral"> (should include language flag)
       <xs:element name="start-date" type="dcterms:W3CDTF" minOccurs="0"/>
       <xs:element name="end-date" type="dcterms:W3CDTF" minOccurs="0"/>
       <xs:element ref="kml:Location"/> (should be taken from xmlns:kml="http://earth.google.com/kml/2.1" namespace)
   </xs:element>

--Natasa 16:05, 10 December 2007 (CET)

- Please provide a concept, may be as a colab-page There should be a description for each new/changed method, its filteres and their meenings.

Summary of this is:

Modification:
- create organizational unit should create org units with status "created"
- method "delete" should be updated to allow deletion of organizational units only in case when they have no children and when they are in status "created"

New methods:

- method to "open" organizational unit is missing
- method to "close" organizational unit is missing

An organizational unit can be closed if the following conditions were met:

(has no children in status "opened") (in case there are no chidlren at all it can be closed as well)--Natasa 10:23, 7 December 2007 (CET)

Additional issues:
- data consistency is not implemented properly at the moment.

Organizational units can be associated with the Context only if OrgUnit status is "opened"

A context object has organizational units related. When a context object is created only organizational units in status "opened" can be related as responsible for the context.--Natasa 10:23, 7 December 2007 (CET)

Organizational units can be associated with Users only if OrgUnit status is "opened"

When a user is created a relation to an organizational unit from which this user comes from is also created. In this case organizational unit that is given during creation of a user must be in status "opened".

Organizational units can be deleted only if OrgUnit status is "created".

And when there are no children in status other then "created". --Natasa 10:23, 7 December 2007 (CET)

Other relations to/from org units also need to be considered .

OK we will extend the decision table given in one of the links below (history of organizational units) and create a separate page.--Natasa 10:23, 7 December 2007 (CET)

Please check the following page (concept) and put your further questions Talk:PubMan_Func_Spec_Organizational_Unit_Management--Natasa 10:51, 7 December 2007 (CET)

Item handler[edit]

extend filters to "last-modified-since", "context", "related-to" (not only with id of the item, but also with a set of relation types)
separation Filter/Search - Frank

There should be a description for each new/changed method, its filters and their meanings see page Item Handler

New service Ingestion[edit]

posting of named graphs of objects, pushing/pulling functionality?

see concept on page Ingestion Service

New service Relation Handler[edit]

create, retrieve, modify, update relation objects, register new relation types

see concept on page Content relations

Service repository[edit]

Service repository (for all, not only for core services)
- Service repository of eSciDoc
- Service repositories in general