MPDL AB Meeting 2009-10-21

MPDL  Restricted Access to MPDL
 * Participants: Natasa Bulatovic, Tom Endres, Tobias Schraut, Michael Franke, Wilhelm Frank, Markus Haarländer

URLs
Proposal for following structure of the URLs in all three solutions so far is:

PubMan

 * PublicationItem URL in ViewItemPage:
 * present state: baseURL/faces/viewItemFullPage.jsp?itemId=[item-id:version]
 * proposed: BaseURL/item/[item-id:version]
 * BaseURL should not be [pubman-solution-url/pubman]


 * PublicationItemComponents:
 * present state:
 * content: BaseURL/item/[item-id:version]/component/[component-id]/file-name
 * component content also retrievable via BaseURL/item/[item-id:version]/component/[component-id]/content
 * rule if:
 * component view if ever would be defined (not download the content): BaseURL/item/[item-id:version]/component/component-id


 * PublicationManager containers e.g. Yearbook
 * proposal: BaseURL/container/[container-id:version]

FACES

 * FACES Item
 * present state: BaseURL/details/[item-id] (BaseURL fine, as it does not contain "/faces" similar like for pubman)
 * proposed state:BaseURL/member/[item-id:version]


 * FACES Album
 * present state: BaseURL/album/album-id
 * proposed: no change needed


 * Faces NotePad
 * no present state, is an item - but may get tricky for implementation, to be discussed

VIRR

 * same problem as for Faces, here we have 2 types of containers


 * VIRR Volume
 * present state: baseURL/view/volume/[container-id:version]
 * proposed state: baseURL/volume/[container-id:version]


 * VIRR Multivolume
 * present state: baseURL/view/multivolume/[container-id:version]
 * proposed state: baseURL/multivolume/[container-id:version]

baseURL/view/volume/[container-id:version]/toc/[item-id:version]/[scan-number]
 * VIRR TOC (Browse Work)
 * present state: baseURL/view/volume/[container-id:version]/[scan-number]
 * proposed state: baseURL/view/volume/[container-id:version]/toc/[item-id:version]/[member-id:version] OR

Question

 * can it be done even more generic, such as "baseURL/object-version-id" respectively in all solutions?
 * i don't see why solution urls would need this much genericity. the generic urls for tha data are already available from the core service; and just like the solution adds meaning to these generic resources it may add some semantic to the URLs it exposes.--Robert 14:11, 15 October 2009 (UTC)
 * the more i think about it the more i like the solution-specific semantics of the URLs. isn't it exactly the service of a solution that it gives a particular meaning to an otherwise generic resource? when i look at faces, i have an idea what an album may be, but i'm not interested in containers.--Robert 19:11, 15 October 2009 (UTC)
 * that's correct argument, for the current solutions these would make not much sense. If you would like to mash-up some data - that would be additional stuff, as then it all comes to "resource" - that was initial thinking of trying to avoid content-model specific labeling from the URLs. --Natasa 13:42, 16 October 2009 (UTC)
 * another (maybe false) reasoning was to avoid too much additional mapping (i.e. from e.g. album to container) when it comes to smth. like content negotiation we would like to have in future. But maybe the URL of the solution is the wrong place to think of it.
 * i don't understand. as far as i can see, the URLs have nothing to do with content negotiation (or a lack of it). i would think that a solution should add specific semantics to all the content types it serves up for a resource, i.e. while the core service may not be able to provide anything but application/xml for a resource (and maybe application/rdf+xml), a solution could offer application/vnd.google-earth.kml+xml if it knew the resource contained some geo data.--Robert 14:55, 16 October 2009 (UTC)

Will make some changes in proposals --Natasa 13:46, 16 October 2009 (UTC)


 * another note: faces and pubman are already considered in prodution use; thus changing the URLs (i.e. the external interface of the application) is not something to be taken lightly.--Robert 14:59, 16 October 2009 (UTC)
 * well, we certainly would like to change the "baseURL/faces/viewItemFullPage.jsp?itemId=[item-id:version] " variant to be shown as URL address --Natasa 07:53, 19 October 2009 (UTC)

Service architecture

 * to understand what are the steps to be taken to support flexibility in following manner e.g. allow for using of new stuff as long as service interfaces are not changed:
 * citation manager: adding new citation style/modification of existing style should not require new release of solutions that use it
 * validation service: adding new/modification of existing validation schema should not require new release of solutions that use it
 * transformation: e.g. if xslt based transformation, adding new/modification of existing transformation should not require new release of solutions that use it

Metadata design JusCMS

 * see outcome at Discussion on Metadata re-design for JusCMS

JusCMS Customization

 * General approach to customize PubMan in following manner:
 * customize for extension of messages for particular genres
 * customize on PubMan instance level
 * check indeed if JusCMS should run as separate instance
 * may be related to instance separation mentioned as well by AWI