Talk:MPDL AB Meeting 2009-08-19

Questions/Thoughts for AB discussion:

• did not understood the remark on non-generic solution while adding new genres
  • PubMan metadata profile at present uses a fixed list of genres
  • Which context uses which genres is in the admin descriptor of a context
  • might a start of a generic solution be moving the genre lists to Cone?

• the metadata which are JusCMS specific
  • according the table the only metadata that are JusCMS specific are related to the case and case metadata, whereas the only new metadata is the eterms:court metadata.
  • if we use the "dumbing" approach, we may map the court institution to the publisher of source (e.g. 2nd source) in this case, or this smth different?

• GeoMetadata in separate MDRecord
  • geo metadata are very different type of metadata, and these are to be certainly approached as separate metadata record, these will most probably even be edited independently on the bibliographical metadata

• JusCMS metadata only in separate MDRecord
  • my first impression is that this may cause many troubles e.g. spanning the validation for 2 metadata records, spanning the editing/viewing of the publication for 2 metadata records at once, revision of advanced search? ... this is reducing the pubMan possiblity and adoptability to easily work on external metadata as core publication metadata ...

• • on the other hand, does it makes sense also to think on whether the case itself is a separate resource (separate publication item), thus relating the e.g. article publication item with the case item would be actually the approach?

• • imho JusCMS metadata are still part of the publication metadata profile -> they are just there for some genres and not there for some other genres

• • an aspect to also understand is: core services allow for independent modification of each metadata record separately (not certain if that is smth critical, just trying to list it all

• PubMan and 2 metadata records
  • pubMan had never dealt with more than single metadata record - in terms of implementation this may be more work then we can assume, but this is to be judged more precisely within AB team
  • if we still stick to the decision of putting separate metadata record, i would suggest for indeed doing-it rest-style like provided from the core-services e.g. demark them clearly on both edit, view interfaces

• Adding second metadata record complex or not?
  • maybe we should understand what are the cases when we would have to add second metadata record indeed vs. when we would consider smth as separate resource (e.g. Project) and enable linking to another item vs. when it is indeed a separate metadata record (e.g. GeoMetadata, original metadata from imported item etc.)

Architectural Bord

Publication Management