User talk:Natasab
ViRR[edit]
Hi Natasa,
would it be possible to move your to do list for the first prototype of ViRR 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 (CET)
- Done. See Talk:ViRR_Scope#Short_ToDo --Natasa 10:31, 7 March 2008 (CET)
Revision of Talk:PubMan_Indexing[edit]
- 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 (CET)
- revision of page PubMan Indexing, e.g. by extending the examples provided by you. Please note that the example "ISBN 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 "ISBN 0899" automatically to "ISBN 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 (CET)
- 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 PID of the "MPG" (that needs to search also all departments below MPG). --Natasa 09:48, 25 February 2008 (CET)
- 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 Colab discussion page was actually put to enable fast input to Michael from more people around. --Natasa 09:48, 25 February 2008 (CET)
Best wishes --Inga 14:22, 19 February 2008 (CET)
ThnX a lot! --Natasa 09:48, 25 February 2008 (CET)
Naming pages (dates & more)[edit]
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":
- DeveloperMeeting ddmmyyyy -> MPDL Developer Meeting yyyy-mm-dd (I'm not sure... are these meetings escidoc specific or do you discuss other subjects as well)
- DeveloperWorkshop ddmmyyyy -> eSciDoc Developer Workshop yyyy-mm-dd
- DeveloperMeeting JavaWebFramework -> Java Web Framework Evaluation
- 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 (CET)
- Hi dear,
- I have no preferences for the naming convention. The logic beside the pages was:
- they are protected to the eSciDoc group (which is all developers)
- we discuss issues not solely specific on eSciDoc (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 eSciDoc team :)
- i was thinking that categories are sufficient - therefore was not putting anything specific on eSciDoc or MPDL 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 (CET)
- Done ;) --Inga 14:37, 26 November 2007 (CET)
Formatting comments[edit]
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 CoLab 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 (CEST)
- Hi Dear! --Natasa 10:20, 28 September 2007 (CEST) 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[edit]
- Transition of item status is never changing the version number
- Below transitions to be reconsidered
Current implementation of transitions[edit]
| 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[edit]
| 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[edit]
FACES: Surrogate Items[edit]
- 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 FIZ)
- would mean two possibilities:
- 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[edit]
- cd /srv/escidocadmin/
- svn up
- rctgescidocadmin restart|stop|start
IEEE Conference paper[edit]
- http://www.ieee.org/documents/auinfo07.pdf
- catch-up on list of references
- deadlines: http://www.icde2011.org/node/9
( 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