Differences between revisions 1 and 14 (spanning 13 versions)
Revision 1 as of 2008-08-18 06:32:52
Size: 3121
Editor: kfc
Comment:
Revision 14 as of 2008-09-01 12:20:17
Size: 4351
Editor: abr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
 Assigned:: ABR+EK  Assigned:: KFC + ABR + EK
Line 21: Line 21:
 Tasks adressed:: ["TaskX/1"]  Tasks adressed:: ["TaskA.2.2"],["TaskA.2.1"]
Line 27: Line 27:
 Time estimated:: not done  Time estimated:: 8md
Line 33: Line 33:
 Time used:: 0md  Time used:: 3md
Line 39: Line 39:
 Priority:: ?  Priority:: 6
Line 45: Line 45:
 Status:: Not started
 Status:: In progress
Line 71: Line 70:
The issues we have identified so far:
 * Inheritance is not implemented, but two equally useful ways present themselves. Choosing the one that Fedora will use will help our system gain acceptance.
 * Arbitrary xml in DS-COMPOSITION, instead of SCHEMABINDINGS
 * rdf:type and a OWL Full to describe the relationsship model
 * Policy Relationships
 * The schemas for the Base objects datastreams must be decided and formalised.
 
The purpose of this action is to establish how key concepts, mainly inheritance, should be implemented, and formalise the DOMS base collection. We should start manipulating the Fedora developers into accepting our wishes, mainly by emails to their mailinglists.
Line 72: Line 79:


The product should be a datamodel description, and the foxml object for the Base collection.

== Progress ==

=== DS-COMPOSITE ===
We use DS-COMPOSITE to store arbitrary metadata, as proposed. Fedora does not choke on it, and preserves it faithfully.


=== DOMS owl ontology ===

The Fedora OWL ontology system we will use have been defined in FedoraOntology. It lacks review.

=== TODO ===

The TODO list from [:ActionDataModelTDRRequirements:] has been added to [:TaskA.2.3AnalysisDocument:].

Action decide Data Model with respect to Fedora 3

Assigned
KFC + ABR + EK

Prev assigned

Tasks adressed
["TaskA.2.2"],["TaskA.2.1"]

Time estimated
8md

Time used
3md

Priority
6

Status
In progress

Iteration
11

Notes

The Fedora 3 Data Model seems to indicate a different datamodel to what we expected, and this has impact on how we should define the final DOMS data model. This needs to be decided, and soon, so Mjølner knows how our final datamodel looks.

The issues we have identified so far:

  • Inheritance is not implemented, but two equally useful ways present themselves. Choosing the one that Fedora will use will help our system gain acceptance.
  • Arbitrary xml in DS-COMPOSITION, instead of SCHEMABINDINGS
  • rdf:type and a OWL Full to describe the relationsship model
  • Policy Relationships
  • The schemas for the Base objects datastreams must be decided and formalised.

The purpose of this action is to establish how key concepts, mainly inheritance, should be implemented, and formalise the DOMS base collection. We should start manipulating the Fedora developers into accepting our wishes, mainly by emails to their mailinglists.

The product should be a datamodel description, and the foxml object for the Base collection.

Progress

DS-COMPOSITE

We use DS-COMPOSITE to store arbitrary metadata, as proposed. Fedora does not choke on it, and preserves it faithfully.

DOMS owl ontology

The Fedora OWL ontology system we will use have been defined in FedoraOntology. It lacks review.

TODO

The TODO list from [:ActionDataModelTDRRequirements:] has been added to [:TaskA.2.3AnalysisDocument:].

Checklist For Working On An Action

The Life Cycle of an Action:

  • Assign people for action definition: Done at start of iteration status meeting. Fill out Assigned

  • Define the action: Describe information about what is to be done and how. Fill out Tasks Addressed and Time Estimated.

  • Review the definition: Get another project group member to review the action definition, and update it.

  • Assign people for action implementation: Done by project manager, usually the same persons who wrote the definition. Fill out Assigned and Prev assigned if new persons are assigned.

  • Implement the action: See details below

  • Review the action: Get another project group member to review what is implemented (code and documentation), and update it.

  • Finish the action: Change the status to "Finished" and update the "time used" field on the action page.

Please make sure that you address the below issues, when working on an action:

  • Update the state of the action to "In Progress" when you start working on it.
  • Check if the tasks addressed by this action have their status set to "In Progress". If that is not the case, then change the state of them.
  • Keep track of how much time that has been spent working on the action. If it addresses more than one task, then make a note on the action page about how much of the elapsed time that has been spent on the individual tasks. Hint: Continually updating the "Time used" field will make it easier for you.

  • Update the "Progress History" and documentation pages of each task addressed by this action when appropriate. This depends on the situation, but in general, the task pages should hold all important related information about the work done, experiences gathered, identified requirements and so on.

ActionDataModelFedora3 (last edited 2010-03-17 13:12:54 by localhost)