## Please put instances of this task in the subfolder Tasks/ with name for the number, and subfolders as approproate, e.g. Tasks/X/Y ## If any of the below links or sections are not applicable to your page, then please comment them out rather than deleting ## as they may become relevant later on. ## Headline like "Task Implement Backup" = Task ECM = ## Task title Title:: ECM ## Valid states: "Not started", "In progress" and "Finished" State:: Not started ## The time used is measured in man days and does not include the time spent on any sub-tasks. As a rule of thumb, time should always be allocated to subtasks, rather than parent tasks. Format: Xmd Time used:: ## As time used Time estimated:: 11-13md == Description == /!\ Updated after the planning meeting ## Add a high level task (goals / sub-goals) description here, sufficiently detailed to provide a background for creation of action descriptions. ## Any available (technical) details goes into the below documentation pages. ECM is both the better content model system, and a webservice for performing certain tasks on fedora. It is to be moved into Fedora. For the purposes of DOMS, we do not allocate ressources for this work, but only for the things that are directly relevant for DOMS. State: A rest based webservice, that uses Fedora client to speak with Fedora. Design of ECM is close to final. Outstanding tasks 1. Finalise design of ECM 1. Schema location bug: Use the "datastream as URL" workaround. 0 1. Namespaces. Use whatever is current in the latest iteration of ECM. '''1C''' If we need to change, it is only the CMs that must change, not the data objects. 1. DS-COMPOSITE-MODEL. Little change with the roll-in to Fedora, which necessitates a change to the webservice. 1A. RelsInt support postponed. 1. Ontology syntax. The final decision on how to designate relations (with # and so on) in the ontologies. '''Re-estimated: Use whatever works, ECM is the only system that will read ontologies in the forseeable future: 3B''' 1. Add collection based operations. All collection based operations are queries. As such, they are easy to implement, as ECM has a good query framework. But many operations, and review, so 4B. 1. Pid generator. The Pid generator is written and ready. It is a soap webservice. ECM has a pid generator interface, behind which it hides an implementation. This should be the soap client to the pidgenerator webservice. 2B, as we need to add config params to web.xml for the soap client, but otherwise very basic codechange. Tasks needed by the Update tracker 1. Update View system to take date as a parameter. This is needed by the Update tracking stuff, where you need to get the object view bundle as it looked at a certain date (when it was published). Fedora already takes date as a param for most stuff, so this should just be propagated upwards. 2B Future tasks 1. Name-spaces. We need to agree on the ECM (and DOMS) name-spaces. This involves a meeting, updating all docs marked as current, and updating the ECM webservice. Combined, this is 5B, as we know quite well what should be done, and ECM is quick to update, but the meeting might take time, and the docs can be nasty. 1. Schema location bug. Schemas that import each other need an absolute URL. 7C, as this bug has been with us for some time. We have a design, but if that fails we knows not what to do. There are workarounds, that can be used just for DOMS, through. 1. Bring Validator service into Fedora. RelsInt support estimated at 5C, but there is more to this task. 1. To use a better way of speaking to Fedora. Fedora releases a new java Client in 3.4. Migrate ECM to use this. 3C, as new tech, but the client code is isolated in ECM. == Sub tasks == <> == Documentation == ## The documentation section links to the documentation relevant to this task and its sub-tasks (if any). ## ## The below links will automatically be expanded to page names like "Tasks/X/Y/AnalysisDocument" in your created page. ## This should be a proper default. ## ## DO NOT comment out these links. * [[Tasks/24/AnalysisDocument|Analysis Document]] * [[Tasks/24/DesignDocument|Design Document]] * [[Tasks/24/SystemMaintenanceDocument|System Set-up and Maintenance Document]] == Progress history == <> ## Add information about about the current state of the task here. That is, information about what has been completed so far and ## what outstanding issues are left. Example: ## ##=== 2007-09-13 === ##Finished the design documentation. A review is needed before this task is completed. ## ##=== 2007-08-25 === ##Completed requirement specification. We are now ready for writing the design document.