Difference between revisions of "User:Floebe"

From Openresearch
Jump to: navigation, search
(Tutorial Contents for Users: moved to ./Tutorial)
(For Scientists: + an idea for hiding contents)
 
Line 64: Line 64:
 
*** management of events related to submissions (to be considered for submission, where sth was submitted etc.) or participation
 
*** management of events related to submissions (to be considered for submission, where sth was submitted etc.) or participation
 
*** generation of next years lists via conference series (e.g., if RuleML 2008 was interesting for submission in 2008, the 2009 event could be copied to the submission list for 2009)
 
*** generation of next years lists via conference series (e.g., if RuleML 2008 was interesting for submission in 2008, the 2009 event could be copied to the submission list for 2009)
 +
*** on publicity: introduce pages representing relations with an encoded name, and use one or a few general relations to link to other pages; this should allow for listings on those encoded pages which correspond to what one would like to remember ... ''to be tested''
 
** benefits over personal solutions
 
** benefits over personal solutions
 
*** information is updated by all
 
*** information is updated by all
*** available in RDF  
+
*** available in RDF
  
 
== For Conference Organizers ==
 
== For Conference Organizers ==

Latest revision as of 11:11, 26 September 2008

See Frank Loebe for general information in OpenResearch, or go directly to my workpage at https://wiki.imise.uni-leipzig.de/FrankLoebe .

Improvements to OpenResearch

Organizational

Major

  • the underlying ontology
    • I see major problems of a coordinated evolution of the underlying ontology, i.e., that people use the right relationships etc.
    • How will the model evolve, who adapts the data to this?
    • I believe that dedicated editors are required to harmonize the categorization of entities into subject fields


  • how to treat the temporalization of the data
    • e.g., if the editorial board of a journal changes
    • Options
  1. Keep only current info as semantic, historical should reside in the histories
  2. Try to maintain past info as semantic, e.g. "had EB member" ... but a better solution is required.

Minor

General Policies

  • use of abbreviations for URIs is no good idea, because if all science is to be covered, there will be many disambiguations
ex: AAMAS = (Autonomous Agents and Multi-Agent Systems, The American Association of Medical Audit Specialists, ...(?) )

Events

  • sometimes, event descriptions can have "resort names" or "hotel names" as more precise specification of the hotel -> not covered in the ontology
  • there are at least two types of (initiating) submission dates to be distinguished:
    • submission of an abstract
    • submission of the paper
  • Concerning the description of Template:Event: how do "submission deadline" and "paper deadline" relate to each other? The explanatory note sounds like "paper deadline" is-a "submission deadline". On the one hand ok, on the other I see the problem for lists of upcoming deadlines that one must see the abstract submission deadline first, otherwise you may miss that.
My proposal on this issue: in the ontology, view "abstract deadline" as well as "paper deadline" as "submission deadline" and find a solution for displaying tables which have several "submission deadline" links. (How do the tables treat multiple entries/1:m relations, actually?)

Journals

  • Journals can have an ISSN assigned, as well as an E-ISSN
ex: http://journals.cambridge.org/action/displayJournal?jid=KER
  • Journals can have several editors
ex: http://journals.cambridge.org/action/displayMoreInfo?jid=KER&type=eb

Technical

Implementation Changes Required

Major

Minor

  • The Property:Homepage should not always add a "http"-prefix, because one may link to pages with other protocols like https, ftp, etc. Moreover, I suggest this in general for all uses of the property, because e.g. for copying links a browser context menu, the "http"-prefix is included in the copied text. Then, it is annoying to remove it. The best solution for editing would be to detect whether there is a protocol part at the beginning, then keep it, and if not, add "http" as default. For viewing, one may similarly cut off the http-prefix. Personally, I don't find it disturbing.
ex1: my homepage has a "https"-prefix.
ex2: I had the editing problem on the RuleML 2008 page, pasting the link into the field.

Nice to have

  • open 13.09.2008 edit support for selecting ontology entities
Editing support for selecting semantic properties and classes would be highly beneficial, e.g., enhancing the toolbar of the editing field with a class and a property browser would be a first step.
(Meanwhile, the listings at Special:Categories and Special:Properties are valuable.)

Integration of Existing Data

  • get Persons, Journals, Conferences etc. from DBLP
in general, it should be a good idea to cooperate with them, perhaps cross-link

Legal Issues

  • Can one simply copy short descriptions from other websites?
ex: The short description of KER from [1] for The Knowledge Engineering Review

Potential Use Cases for OpenResearch

For Scientists

  • personal event listings
    • ideas
      • management of events related to submissions (to be considered for submission, where sth was submitted etc.) or participation
      • generation of next years lists via conference series (e.g., if RuleML 2008 was interesting for submission in 2008, the 2009 event could be copied to the submission list for 2009)
      • on publicity: introduce pages representing relations with an encoded name, and use one or a few general relations to link to other pages; this should allow for listings on those encoded pages which correspond to what one would like to remember ... to be tested
    • benefits over personal solutions
      • information is updated by all
      • available in RDF

For Conference Organizers

  • CfP generation
    • ideas
      • new workflow for CfPs: add stuff to OpenResearch via Templates, generate a pre-CfP from this, then a final edit; this requires e.g. plain-text export templates (to send CfP mails).
      • if no changes are made to the CfP, one may even record to which lists it should go and send it from OpenResearch; but I don't think this will be adopted soon.