Talk:PubMan Func Spec Browse By
browse by organizational unit
browse by creator
- It is not clear from the overall description of the use case if it should include only CoNE persons or any creators in the publication metadata.
- I would only see CoNE persons here.--Friederike 14:07, 22 February 2010 (UTC)
- --Ulla 14:28, 22 February 2010 (UTC): CoNE persons might be the easiest starting point. Still, I assume, that it might be hard to understand for anonymous users from outside (as number of search result might differ from e.g. advanced search). In addition, when providing Cone persons AND any creators of the publication metadata, it would have benefit of explicit mis-match of pubcliations, which have partly Cone persons assigned and partly "not-cone" persons assigned. (Example: Cone person Kleinfercher has 20 publications, "string" kleinfercher has additional 10 publications => Cone Editor should check)
- --MFranke 15:11, 22 February 2010 (UTC) We currently do not have an opportunity to easily retrieve the whole list of creators from the search. This might be a future extension point for FIZ. So we are only able, after choosing a leading character, to retrieve all publications with creators starting with that characters. Getting more and more content this is not feasible. On the other hand it might be a benefit of using CoNE persons to build the list that we can control the list. Looking at the AEI publications we have publications with 800 authors where only a handful are working at the institute. All others, coming from external organizations, would also be displayed in the "Browse by" page.
- After discussion with Michael we would propose to start in 6.1 with only CoNE persons, as the scan query would need to be improved and code changes would be necessary. In a next release we can tackle Browse By any creator (not only CoNE). But even then I would keep the lists controlled and all persons separated--Friederike 16:08, 22 February 2010 (UTC)
- if only CoNE creators are offered for browsing, then this could easily be only CoNE functionality (pubMan would then re-direct to CoNE browsing pages only).
- --Ulla 14:29, 22 February 2010 (UTC)In addition, would propose to use any creator role, both on item level and "source" level.
browse by genre
Removed this UC, as I think the same func can also be done via the advanced search
browse by subject
most probably there are two types of subject browsing:
a) Controlled Vocab /DDC, PACS other) - this could be the browsing tree
b) free keywords - this can not be browsing tree, should be tag cloud .. ex. http://coreservice.mpdl.mpg.de/srw/search/escidoc_all?operation=scan&scanClause=escidoc.publication.subject%20%3E%20%27%27 (scan clause on subjects)
(unfortunately, pubman 6.0 does not display subject in the view item page, see http://subversion.mpdl.mpg.de:8080/browse/PUBMAN-1385)
--Ulla 14:34, 22 February 2010 (UTC): Would go for option a) as starting point. Additional complexity comes in, as Controlled Vocab might be context-specific, i.e. browsing user might need to choose to browse by either PACS or DDC or local-specific Controlled vocab.(Use case MPI Physik komplexer systeme) When it comes to ordering, would opt for alphabetical sorting, as numbers are not known/intuitive. In case of Numbered CVs (such as DDC), each "number" correspond always to an semantic entry.
- Would propose same as for creators. For start we only implement Browse By Controlled Vocab (DDC, PACS, etc.). And we can tackle free keywords at a later stage.--Friederike 16:18, 22 February 2010 (UTC)
Browse by Subject: Classification of MPI PKS
- MPI PKS requires the integration of the following 14 Topics as controlled subjects with the possibility to browse by:
- 1. Light-matter interaction
- 2. Ultracold matter
- 3. Semiclassics and chaos in quantum systems
- 4. Atomic and molecular structure
- 5. Electronic structure
- 6. Superconductivity and magnetism
- 7. Phase transitions and critical phenomena
- 8. Strongly correlated electrons
- 9. Time dependent processes
- 10. Living matter
- 11. Stochastic processes
- 12. Deterministic dynamics
- 13. Structure formation and active systems
- 14. Dynamics in nanoscale systems
browse by collection
- do not understand what browse_by collection is : browsing by context?
- contexts are not public objects, therefore these can not be browsed by public users
- if needed anyhow, these should only be available for the users with depositor/moderator privileges
- next question is whether all contexts should be shown in the tree or only those for which user has above privileges
--Ulla 14:35, 22 February 2010 (UTC)can be ignored;-)
UC removed.--Friederike 14:52, 22 February 2010 (UTC)
browse by journal
- same question as for browsy by creator
- I would only see CoNE journals here.--Friederike 14:07, 22 February 2010 (UTC)
--Ulla 14:35, 22 February 2010 (UTC) not of big relevance to my understanding...is better covered by adv search
- I think this UC could be of interest if we can provide the number of items behind each journal or display only journal which have related items. Here one could see in which journals the MPG publishes. But if no requirement from an institute exists we should not tackle it in R6.1 (if at all?)--Friederike 14:55, 22 February 2010 (UTC)
- I also think it could be an interesting scenario, but agree to Rike that it only makes sense if a number of published items is displayed beside the respective journal. Starting with "Browse by CoNE journals" would be a worthwile thing, I think. --Juliane 13:52, 24 February 2010 (UTC)
browse by year
--Juliane 14:01, 24 February 2010 (UTC):
- regarding your question which year range to choose for displaying. maybe we could design it like that:
- 1990 - 1999 (displayed when user chooses to browse by year)
- 1990 (displayed when user chooses to browse within the respective year range)
- 2000 - 2009 (displayed when user chooses to browse by year)
- 2000 (displayed when user chooses to browse within the respective year range)
- 2010 - 2019
- 1990 - 1999 (displayed when user chooses to browse by year)
- The problem is that we have already older publications in pubman (sengbusch collection), Thus I would propose to make a search for the 'oldest' publication and start with this year. Have to check with if such a query is possible.--Friederike 14:24, 24 February 2010 (UTC)
- Yes, of course, that is what we have to find out - I assume that's a kind of administrative search --Juliane 14:30, 24 February 2010 (UTC)
- would be good to think if it pays of to have more generic definition of the browsing trees (e.g. define index and query).
- thus these could be easily added /replaced any time needed on any instance
- --Ulla 14:36, 22 February 2010 (UTC) Browse by Year (publication date OR any date) might be another interesting browsing option
- Nice idea, will integrate it.--Friederike 14:58, 22 February 2010 (UTC)
- --Ulla 14:38, 22 February 2010 (UTC) Any browse-by option should have preview of hits in brackets, e.g. browse by creator kleinfercher => Kleinfercher, Friederike (20)
- If this is possible regarding the performance it would be nice!--Friederike 14:58, 22 February 2010 (UTC)
- --Ulla 14:41, 22 February 2010 (UTC)difference to "faceted search"?
- This in fact is kind of a simplified faceted search, where we define the entry points.--Friederike 14:58, 22 February 2010 (UTC)
- for previous ideas see also https://subversion.mpdl.mpg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Usage_Scenarios/Publication_Management/Browsing_Display/usc_pubman_browsing.doc
- Is it possible to combine the display of 'browse by' values with a search, so that only values are displayed which have related items? E.g. Only display Collection which has released items in it? Is this doable due to performance issues. Do we want that?--Friederike 10:08, 22 February 2010 (UTC)
- This will be possible with the scan query mentioned from Natasa. Not for 6.1 as the scan query seems to be buggy and heavier code changes would be necessary.--Friederike 16:02, 22 February 2010 (UTC)
- --Juliane 14:07, 24 February 2010 (UTC): Browse by language as well as browse by event might be further interesting browsing options. Maybe not for R6.1, but later on?