User talk:Natasab

From MPDLMediaWiki
Jump to: navigation, search

ViRRVirtueller Raum Reichsrecht

Hi Natasa,
would it be possible to move your to do list for the first prototype of ViRRVirtueller Raum Reichsrecht from Talk:ViRR_Specification to Talk:ViRR_Scope because your list refers to R1 (not to the general specification), so perhaps it would better fit to the Scope page.
Please let me know it that would be fine fore you, than I can do the moving.

Thanks and cheers --Kristina 10:09, 7 March 2008 (CETCentral European Time)

Done. See Talk:ViRR_Scope#Short_ToDo --Natasa 10:31, 7 March 2008 (CETCentral European Time)

Revision of Talk:PubMan_Indexing

Hi dear, thnX for comments.

Hi dear,
today, I checked the escidoc indexing stuff and hope that this wasn't too late. Some remarks:

  • re-formatting of page Talk:PubMan Indexing due to the fact that the former version was very hard to understand. In rare cases this required me to guess the creator of a statement. Please check the discussion page above and feel free to correct any error I may have introduced while revision ;)#
Fine, this was done in a rush to be able to fast communicate with Michael. It's better now. --Natasa 09:48, 25 February 2008 (CETCentral European Time)
  • revision of page PubMan Indexing, e.g. by extending the examples provided by you. Please note that the example "ISBNInternational Standard Book Number 1234*" is not in sync with the specification provided in PubMan Func Spec Search: Within a phrase token, no wildcards are allowed. Phrases are automatically right truncated, thus in its context, the phrase may be followed by any character.
    Is it true that the pubman application transfers the search query "ISBNInternational Standard Book Number 0899" automatically to "ISBNInternational Standard Book Number 0899*"? Do we expect the framework to support right masking of phrases as defined in the CQL spec? In this case, we might note down these requirements somewhere...
Clarified a bit on the discussion page: It was never an intention to use the identifier (type, value) as phrase search. I used "..." as examples for query criteria to delimit them from the other text. All values should be indexed as separate tokens and as a combination together. I only provided the examples. --Natasa 09:48, 25 February 2008 (CETCentral European Time)
  • organization: It looks like your extension to the organization search expresses the need from the browse by affiliation use case. Are you sure, that this should be done via the same index?
It is an index for some metadata of the organizational units, and I only added the requirement for extra indexing of an organizational unit path (under the name of Organization). It is in fact another index named "any-organization-pid" in the implementation to my understanding. Browse by affiliation is only one use case. Another use case is advanced search for e.g. provided PIDPersistent Identifer or Identification of the "MPGMax-Planck-Gesellschaft" (that needs to search also all departments below MPGMax-Planck-Gesellschaft). --Natasa 09:48, 25 February 2008 (CETCentral European Time)
  • identifier: Again, I would suggest to split identifiers into two indexes (system/external), a "search-for-any" identifier could be implemented on the top
Fine with me. It is a matter of implementation and I am not really an expert for searching. The ColabCollaboration Laboratory discussion page was actually put to enable fast input to Michael from more people around. --Natasa 09:48, 25 February 2008 (CETCentral European Time)

Best wishes --Inga 14:22, 19 February 2008 (CETCentral European Time)

ThnX a lot! --Natasa 09:48, 25 February 2008 (CETCentral European Time)

Naming pages (dates & more)

Hi dear,
in the colab meeting this monday, we discussed some article naming suggestions. As a result, we added some recommendations to the colab Main_Page#Open_editorial_policy editorial policy. These naming conventions are relevant for some articles created by you (i.e. Category:ESciDoc-Team) and therefore I would like to propose following "moves":

  1. DeveloperMeeting ddmmyyyy -> MPDLMax Planck Digital Library Developer Meeting yyyy-mm-dd (I'm not sure... are these meetings escidoc specific or do you discuss other subjects as well)
  2. DeveloperWorkshop ddmmyyyy -> eSciDocEnhanced Scientific Documentation Developer Workshop yyyy-mm-dd
  3. DeveloperMeeting JavaWebFramework -> Java Web Framework Evaluation
  4. Java Script Framework -> Java Script Framework Evaluation

What do you think? I'm quite experienced with this moving plus correcting cross references... just drop a note and I become active ;)

BTW: I really like both evaluations and consider to add a new category (under article content) for this type of content

Kisses & cheers --Inga 21:40, 21 November 2007 (CETCentral European Time)

Hi dear,
I have no preferences for the naming convention. The logic beside the pages was:
  • they are protected to the eSciDocEnhanced Scientific Documentation group (which is all developers)
  • we discuss issues not solely specific on eSciDocEnhanced Scientific Documentation (even that is the biggest topic always :)
  • e.g. DeveloperMeeting JavaWebFramework was name derived from developer meeting topic :) - and that is still internal only to eSciDocEnhanced Scientific Documentation team :)
  • i was thinking that categories are sufficient - therefore was not putting anything specific on eSciDocEnhanced Scientific Documentation or MPDLMax Planck Digital Library in the page name
Please, if it is not too much of your time- just move these pages. Otherwise let me know I will move them when I have time :)
Kisses&ThnX! --Natasa 09:19, 22 November 2007 (CETCentral European Time)
Done ;) --Inga 14:37, 26 November 2007 (CETCentral European Time)

Formatting comments

Hi dear,
it is quite hard to clearly format comments on wiki pages, i.e. to keep the main content understandable and assign each comment to its owner. The wikimedia manual suggests to intend comments by using colons and to sign the comment at the end, see http://meta.wikimedia.org/wiki/Help:Talk_page#Formatting. I would suggest to follow this recommendation for CoLabCollaboration Laboratory as well and therefore changed your comments in the scope description for FACES accordingly. What do you think?

Many greetings --Inga 19:36, 27 September 2007 (CESTCentral European Summer Time)

Hi Dear! --Natasa 10:20, 28 September 2007 (CESTCentral European Summer Time) I agree.. but please do not take it for bad ... just was not aware of it... Ok... as of this morning put some other comments as well - will go through them again and re-format them..First lessons pay :)) ThnX a lot!


On item statuses and transitions

  • Transition of item status is never changing the version number
  • Below transitions to be reconsidered


Current implementation of transitions

Item status FROM Item version status FROM Method Item status TO Version status TO
pending pending submit submitted submitted
submitted submitted revise in-revision in-revision
submitted submitted release released released
in-revision in-revision submit submitted submitted
released released update(new version created) released pending
released pending submit released submitted
released submitted release released released
released any withdraw withdrawn any
  • Issues
    • The update of released item is done without previous status change
    • This requires the system to have exceptions for privileges
    • if we change the rule on transitions, then users can "fetch" the item for update (which would mean change the version status immediately and only then allow for item modification - would this require new version as well?).
    • Table below shows one example on how these transitions can be made
      • Advantage - clear status transitions for all
      • Drawback
      • many modifications in the code usage scenarios and some in the workflow
      • item can stay forever in a certain status even when no change has been made?
      • current implementation first allows for "create new version of the item with changed status" - thus not touching the existing version -> which may be safer

Alternative A: Possible transitions

Item status FROM Item version status FROM Method Item status TO Version status TO
pending pending submit submitted submitted
submitted submitted revise submitted in-revision
submitted submitted release released released
submitted in-revision submit submitted submitted
submitted in-revision release released released
released released revise released in-revision
released in-revision release released released
released any release withdrawn any(as before)

Alternative B: Possible transitions

FACES: Surrogate Items

  • First sketch
    • Use case that is affected is: add picture to an album
    • Surrogate items are "referencing copies" of the Face items, but they are owned by the user who adds pictures to an album
      • would mean two possibilities:
        • Face pictures are created as locators
        • No locators are created, only metadata + relation "is Surrogate Of - or isDerivedFrom, or isRevisionOf" to FACE item (Check with FIZFachinformationszentrum Karlsruhe)
    • as in Faces there is sharing of albums, many users who share an album can own a surrogate item
    • how to resolve "unshare" and remove items if they are surrogate?
    • how to resolve that all users who share album add/remove surrogate items can remove other users surrogate items from the Album?

eScidoc Admin

  • cd /srv/escidocadmin/
  • svn up
  • rctgescidocadmin restart|stop|start


IEEE Conference paper

( Important Dates

  • Abstract due: July 16, 2010
  • Full paper submissions due: July 23, 2010
  • Author feedback time window: Sep. 24 - Oct 1, 2010
  • Notification of authors: Oct. 30, 2010
  • Final versions due: Nov. 30, 2010
  • max pages: 12 double column