ESciDoc Developer Workshop 2008-12-02

ESciDoc

Date: 02.12.2008 Start time: 14:30

Location: Karlsruhe, München (Video conference)

Participants MPDL: Wilhelm Frank, Natasa Bulatovic

Participants FIZ: Harald Kappus, Matthias Razum, Frank Schwichtenberg, Rosita Fridman

=Agenda=

Previous workshop

 * ESciDoc_Developer_Workshop_2008-11-24-25

Next workshop

 * ESciDoc_Developer_Workshop_2008-12-09

Relations

 * discussion
 * strategie

Outcome

 * There are in general two types of content relations:
 * relations as resources (separate resources with metadata that point to resources they relate) such as: annotations, external tags/bookmarks
 * relations that are part of the resource, are not separate resources and have no metadata (these relations always have as target another eSciDoc/non eSciDoc resource or simply string)
 * it depends on use cases how users would like to create both types of relations
 * we need to find proper name for both types e.g. annotations, simple tags, links etc.


 * Simple relations are part of the resource and are depicted as they are now in the "content-relations" element
 * Annotations (relation resources) are not integral part of the related resources, and they can be retrieved as "virtual resource"
 * each relation resource (annotation) may have own content models
 * each relation resource is versioned/updated independently on related resources


 * Relation ontology - only the term was not clear, now we all understand equally what is meant with relation ontology: it is a set of types of relations allowed to be specified to resources
 * it is agreed that relation ontology we use should actually be persistently identified and available on the WEB rather than having only separate local files (proposal: use PURL/Colab to define them)


 * Discussion on relation handler (to manage complex relations - annotations)
 * for start what is described at content relation handler methods: create, update, retrieve, delete
 * to be checked further and better for task-oriented methods such as: submit(relation-id*), release(relation-id*), withdraw(relation-id*);
 * related resources do not have to be in same context as relation resources
 * relations can be created in any context (separate privs for creation and maintenance of these resources, similar as for other resources) e.g. roles that are able to define/create content relations (simple) are the roles that are able to modify/create resources such as items, containers (e.g. Depositor); roles that are able to define/create content relations (complex) are e.g. Annotator - or same as Depositors?

To-Do

 * MPDL to check more precisely needs/requirements and other relation handler methods
 * Re-Check the outcome and provide more concrete examples (Frank) and discuss it with Natasa, Willy
 * discuss-and-check further
 * discuss-and-check further

Examples I would like to use during discussion
Frank 13:01, 2 December 2008 (UTC)

Stored:   

Query: *  

Stored reification:     Following Persistent 1 a 

Reificated query: SELECT $s WHERE $Statement  $s AND   $Statement  <http://mpdl.escidoc-project.de/controlled/relations/isPredecessorOf> AND   $Statement <rdf:Object> <info:fedora/escidoc:persistent1>

RELS-EXT of a Fedora Object representing a Statement (aka Content Relation): <rdf:RDF> <rdf:Description about="info:fedora/escidoc:1234"> <rdf:type rdf:resource="rdf:Statement"/> <rdf:subject rdf:resource="info:fedora/escidoc:persistent11"/> <rdf:predicate rdf:resource="http://mpdl.escidoc-project.de/controlled/relations/isPredecessorOf"/> <rdf:object rdf:resource="info:fedora/escidoc:persistent1"/> ...  </rdf:Description> </rdf:RDF>

Note: In the above example 'rdf:Statement' is incorrectly used as attribute value instead of the full-qualified URI of RDF Statement.

Content Model

 * see concept and definition at ESciDoc_Content_Models
 * see implementation and example object at ESciDoc_Content_Model_Object

JHOVE integration

 * discussion at ESciDoc_JHove_Integration

Default MD-Records

 * discussion at ESciDoc_Metadata_Records_Manipulation

Outcome

 * Not really happy with this as eSciDoc-core is resource-oriented and should be able to deliver complete resources
 * FIZ needs to check the concept proposal on the linked page first (not done yet)
 * FIZ proposes to have invert methods than proposed deliver retrieveCompleteresource

TOC

 * discussion at ESciDoc_Toc

Outcome

 * Natasa will put the page on Colab

Ontology Manager

 * see ESciDoc_Content_Relations

OAI-PMH

 * MPDL: set up requirements for sets

Outcome

 * what would be good criteria to define sets?
 * what kind of sets we would like to provide to outside?
 * to be able to check if the set definition can be fulfilled by filters
 * FIZ will check if it is able to expose filters as sets
 * MPDL will check better requirements and put on Colab