Updates to Volume/Issue model

TOC features.

Changes: r3647, r3651, r3665

We have exposed the admin interface at r3676 to PLoS to get feedback. Here are some of the key comments:

• Instead of calling it "Human Friendly DOI", we will refer to identifiers as "Volume Id" and "Issue Id"
• Admin will provide the DOI of the article containing the "L" and "S" representation of the immage. If the article has more than the 2 it will be considered an error and nothing will be displayed
• The meta-data displayed with the image in the TOC will be the author list and article abstract
• If no image is available then nothing will be displayed. The PubApp? should handle this case gracefully (for Volume also)
• Sebastian needs to provide look and feel for TOC for PLoS ONE and CT also.
• We have recommended that PLoS use the "doi" scheme to provide identifiers for Volume and Issues.
• Current Issue not automatically populated

Fixes in r3779, r3750, r3748, r3747, r3705, r3701, r3702, r3679, r3677, r3674. A few bugs here still need to be resolved:

• Remove the '[]' in display of lists
• Allow use of [,;\ ] as valid separation characters between list entries (articles, issues, etc.)
• Better error management on lack of requisite information
• Still not sure on modelling
• Predicates need to be finalized.

r3797:

- guard against a null description in the image Article - strip "[]" List.toString artifacts in admin UI forms - allow arbitrary use of [ ,;] as list item separators in admin UI forms

temporarily assigned to Rich to vet the model against intended usage. please assign back to me or note any desired changes. thanks.

i haven't walked through with susanne yet, so i'll keep this for now, but here are my initial questions and suggestions:

• what DOI format is topaz looking for? should it be info:doi/10.1371/... or just doi/10.1371/... or can it really be any old string and we just need to figure it out? let me know if you have a suggestion or aesthetic preference!
• how are issue lists (for volume) and article lists (for issues) delimited?
• it seems strange to me that issues are added manually to volumes AND volumes are added manually to issues. maybe there's some invisible stuff happening and it's already a little more automatic.
  • is it okay for an issue to be in two volumes?
  • i think that if an issue has a given volume id, i shouldn't have to add that issue manually to the volume.
  • the volume should automatically display issues that refer to it, and that list should not be editable.
  • this means that the issue field on the volume form is only used rarely - to include an issue in a volume when it normally would not belong.
  • we now have an implicit concept of a primary volume (the volume id on the issue form) and secondary volume (issues that are added to the volume form).
• the 'volume' field in the create issue form is an Id and should have the label "Volume (Id)" like other Id fields.
• i entered some bad ids/dois on the create issue form and got a site error.
  • what validation and error checking is currently running on which fields, which forms?
  • is there any way to have more informative error messages instead of the default site error?
• does anything prevent an issue from having a previous/next in a different volume?
  • probably nothing should - 01.12 -> 02.01 in most magazine volume/issue schemes...
• display of issues for a volume and article for an issue is hard to use.
  • we could use a text area, at the risk of having a looong page instead of a hard to read field.
  • or could we click through to a separate edit form for each object, so that the display on the manageVolumesIssues.action form is not-editable and concise?
• would it be possible to group issues with their (primary) volumes, instead having all volumes first and then all issues?

susanne adds:

• plosone won't have volumes or issues or a TOC page, will that be a problem?
• we were trying to figure out the ordering of volumes and issues on the manage page. we though that it would make sense for them to order by previous/next (although there's probably ways to make loops and stuff that would break things). however, it looks like volumes and issues are sorted by id, which is fine!

I will answer a couple and let Jeff deal with the rest:

# what DOI format is topaz looking for? should it be info:doi/10.1371/... or just doi/10.1371/... or can it really be any old string and we just need to figure it out? let me know if you have a suggestion or aesthetic preference!

Please see http://www.loc.gov/standards/uri/info.html. As far as Topaz platform is concerned it has to be valid URI. Our recommendation is to use DOI URI's for consistency.

# how are issue lists (for volume) and article lists (for issues) delimited?

As defined earlier in the ticket the separation characters are [,; ], that is comma, semi-colon and space.

Just as another note: Rich and I have talked about this quite a few times and afraid we are not going to be spending time on improving the admin application. This is pretty much throw away code so we have to be careful trying to improve it right now. I don't have enough sense right right now which of the requests above are bugs vs. experience improvement and will let Jeff make that call.

lots of good thoughts.

• the biggest change would be the volume/issue relationship linking. one way to think of it as an implied "rule" for Volumes, e.g. my issues are a query result plus an optional simple collection of manually specified issues, this requires more thought
• I'll see what's simple to do with the UI, the admin app is constrained and this nested/linked editing model stretches it a bit far

Email I sent:

    I finally spent some time looking at Volume/Issue modeling and here are
    some comments:

1.  private String journal predicate in both cases should be the same as
    prism:eIssm that is in Journal.java (if you still want to do this. See (a)
    below)

2.  private String displayName should also have the same predicate for both.
    Recommend PLoS.plos + 'displayName'.

3.  private URI image should also have the same predicate for both. Recommend
    PLoS.plos + 'image'.

Couple of biggies:

a)  The entire idea of aggregation was to be top down, that is, the Aggregation
    object knows what members it has and not the other way around. Here the
    paradigm is being broken by making an underlying object aware of which
    'collections' it is a part of. This will cause huge problems when an "issue" or
    "volume" is made part of another hub.

b)  I am not convinced that Issue and Journal themselves need to be links, that
    is to have prev & next as predicates in each instance. I think it might make
    more sense to take out prev and next from Journal and Issue and make use an
    explicit rdf:list (or rdf:seq) to model the chain of issues or volumes. Please
    take a look at http://www.w3.org/TR/rdf-primer/#containers or
    http://www.w3.org/TR/rdf-primer/#collections. This way your Issue and Volume
    object can be made part of many different sequences in multiple journals/hubs.
    Secondly you don't need two predicates prevIssue and nextIssue. The advantage
    of RDF is that you can walk both backward and forward on a single predicate.

For example:

    <issue1> <next> <issue2>

In rough Oql you can walk forward by:

    select i from Issue i where i.id="<issue1>";

    and i.next will give you issue2

    To get previous issue (say issue0 -> issue1) from issue1 do:

    select i from Issue i where i.next.id="<issue1>";

I am not completely sure on the Oql syntax, but giving you an idea that you
don't have to create forward/backward links. One gives you the other and in a
very simple way. Please note that if you change the modeling to use rdf:seq or
rdf:list you will not have to create these two predicates.


There are two reasons why this is important:

  I) Reduce the complexity of the stored graph
  II) Reuse predicates as far as possible to imply same semantics

To allow external programs to harvest this information all you have to do is
say Issues and Volumes (note: not Issue and Volume) are modelled as rdf
sequences or lists (I prefer lists). There are other ways to model this, but as
long as the basic requirement is to be able to make issues/volumes part of
other journals/hubs, it will have to be done differently then what is there
right now.

we have a new ticket for the ToC page. however, lots of good info on this ticket about where we are with Volume/Issue and what changes are necessary next.

updating title and assigning to 0.8.2

(In [4190]) addresses #628, refactor Volume/Issue - Object models updated per #628:13

• clean up predicates
• remove references to next/prev/containing Object

- updated Admin UI - updated createjournal.groovy script

note that createjournal will need to be re-run on existing databases, existing Volumes/Issues will need to be deleted and re-created

• OK per Russ due to low #

there's unresolved issues with creating Filters for the new Volume/Issue

• Journal can only hold DetachCriteria? for filter rules
• DetachedCriteria? cannot express the Journals contain Volumes contain Issues relationship
• OQL should (must?) be used
• JournalService? is not OQL or full Aggregation friendly?

see

• source:branches/0.8.2/plos/webapp/src/main/java/org/plos/journal/JournalService.java:330
• source:branches/0.8.2/plos/webapp/src/main/java/org/plos/journal/JournalService.java:428

for the existing work-a-rounds, etc.

to allow the new Volume/Issue models to be supported, simple DetachedCriteria? rules were created to allow all Issues/Volumes through the filter. the application UI always requests specific Volumes/Issues.

all ideas and suggestions of a better way solicited.

confirmed fixed in 0.8.2

let's open an new ticket for the filter/aggregation issue.

(In [4330]) Merged revisions 4190 via svnmerge from http://gandalf.topazproject.org/svn/branches/0.8.2

........

r4190 | jsuttor | 2007-12-14 19:01:40 -0800 (Fri, 14 Dec 2007) | 26 lines

addresses #628, refactor Volume/Issue

• Object models updated per #628:13
  • clean up predicates
  • remove references to next/prev/containing Object
• updated Admin UI
• updated createjournal.groovy script

note that createjournal will need to be re-run on existing databases, existing Volumes/Issues will need to be deleted and re-created

• OK per Russ due to low #

there's unresolved issues with creating Filters for the new Volume/Issue

• Journal can only hold DetachCriteria? for filter rules
• DetachedCriteria? cannot express the Journals contain Volumes contain Issues relationship
• OQL should (must?) be used
• JournalService? is not OQL or full Aggregation friendly?

see

• source:branches/0.8.2/plos/webapp/src/main/java/org/plos/journal/JournalService.java:330
• source:branches/0.8.2/plos/webapp/src/main/java/org/plos/journal/JournalService.java:428

for the existing work-a-rounds, etc.

to allow the new Volume/Issue models to be supported, simple DetachedCriteria? rules were created to allow all Issues/Volumes through the filter. the application UI always requests specific Volumes/Issues.

all ideas and suggestions of a better way solicited.

........

Milestone 0.8.2 deleted