Talk:ESciDoc Content Model in Fedora

Copied from: Common Object Properties - Questions and Notes

• status withdrawn not needed
  • maybe we should still keep status "withdrawn" in case when no new resources of this content model can be created ... e.g. legacy data--Natasa 15:33, 9 September 2009 (UTC)
    • I think that may have several issues. E.g. if we have no means to bring a CM out of status withdrawn, does that mean for new objects of that kind i have to create a new CM. Is it valid use case to state there should be no longer appear an object of that kind? Frank 12:31, 10 September 2009 (UTC)
      • not certain if it is a valid use case, but i could assume that we may come in situation that no further objects of this content model can be created - this may be additional assurance to the fact that nobody would have depositor privileges in a context. And yes, this would mean - content model can not be put back in use. --Natasa 14:00, 10 September 2009 (UTC)
• name and description? (cf. Item and Container)
  • a content model object should have a name and a description which might give some textual information about it, rather then purely objid. These might be taken (as in case of items) from a e.g. dublin core metadata record of the content model.
    • Should a CM have md-records? How do we know which one is to be transformed to get title and description? Frank 12:31, 10 September 2009 (UTC)
      • I would assume single metadata record, that allows also to search across content models - it's kind of authoring information which may give additional description what is the purpose of this cmodel, which tools are creating objects of this cmodel, what kind of services user may expect, when not to use it etc... it may be a nice human readable information - despite no particular value for the cmodel and object validation and infrastructure itself. It is not a must, but it would not be an error to have it.. I could even imagine some LinkedData use case popping out of it. --Natasa 14:00, 10 September 2009 (UTC)
• What means the context of a Content Model Object?--Natasa 15:33, 9 September 2009 (UTC)
  • would still keep it: special rights can be managed for each context in which there are content model objects in place. In case of collaborative environments and usage of single repository by different organizations this may be an interesting issue. Another use case which comes up from DARIAH project: content models can be published... so in this case an eSciDoc repository may be a repository of content models (distant use case)--Natasa 15:33, 9 September 2009 (UTC)
    • I think just reuse of CMs may be more complicated with contexts.

I think all three points - and mainly the latter one - are related to sharing of CMs. One idea was to enable the reuse of CMs by others (solutions or even users). That can be just to refer to a CM defined by someone else or to create a copy from an existing CM and refer that copy (here appears the question "in which context i'm allowed to create CMs and can I use CMs from each context?"). That can happen inside one installation of the eSciDoc infrastructure or even between several installation (or off course via a CM-Registry or CM-Repository in the future). We should decide if and how sharing or reuse should be possible. I would not recommend to think about reuse of eSciDoc CMs in other repository systems, at this point. Frank 12:31, 10 September 2009 (UTC)

• • • • agree with you, there are things to be developed still, but still would like to suggest: the context concept is quite nice and why to break the paradigm? If we already foresee these use cases, would not it be useful to just state in CModel: we have context property -> and that is fine, early implementation may skip it's existance and context-based authorization, but we would not have to change the schema again later (at least in this part)? --Natasa 14:00, 10 September 2009 (UTC)

VidConf questions

• neither FedoraCM nor ECM actually suffice for eSciDoc CModel
  • extend ECM or extend eSciDoc Validation service?
• Do we want the validation to be built into Fedora or on eSciDoc layer?
• storing the e.g. metadata xsd for particular CModel may be problematic
  • e.g. CONE stores information on CCLicenses but would allow for refreshing from public source
  • if several CModels use same metadata schema all should be modified
    • It should off course be possible to store the schema as datastream "external reference". Frank 10:57, 15 September 2009 (UTC)
• if ECM ONTOLOGY is used, maybe we could define more generic cModels such as Item and Container
  • all other CModels would extend them, but would not have to repeat all structural and property relations (which is heavily error prone)
    • The internal relations (escidoc structural relations and properties) are not added by the user but by the business logic in respect to the resource type. A user is off course not allowed to change these relations. Frank 10:59, 15 September 2009 (UTC)
• questions
  • what is the eSciDoc purpose of the CModel object?
    • validation
    • generation of views
    • definition of disseminators (services)
    • etc...
    • all previously mentioned
  • long term preservation aspects / interoperability
    • we will provide for lta resources in accordance with item.xsd or container.xsd
    • as CModel definition would be one part of the LTA package together with the item and the container, does it make sense to contain Fedora/ECM internals?
      • From my perspective it depends on what format I want to give for LTA. With eSciDoc Resource XML I would give the eSciDoc Content Model XML, with Fedora Object XML I would give the Fedora Content Model. The eSciDoc Content Model does not contain Fedora internals! Frank 11:02, 15 September 2009 (UTC)
• is initial state part of CModel actually?
  • example PubMan, different contexts, same CModel, different initial state required (accordingly to the workflow attached to the context)
• should eSciDoc CModel contain all settings or only those that can be modified by the end-user?
• simple XML vs OWL vs RDF?

Coordinated Universal Time

Digital Research Infrastructure for the Arts and Humanities

Enhanced Scientific Documentation

Video Conference

Flexible Extensible Digital Object Repository Architecture

Control of Named Entities

Long-term Archiving

Extensible Markup Language

Publication Management

Web Ontology Language

Resource Description Framework