User:Floebe: Difference between revisions
+ ontology > journal editors |
→For Scientists: + an idea for hiding contents |
||
| (20 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
See [[Frank Loebe]] for general information in [[Main Page|OpenResearch]], or go directly to my workpage at https://wiki.imise.uni-leipzig.de/FrankLoebe . | See [[Frank Loebe]] for general information in [[Main Page|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 | |||
:# Keep only current info as semantic, historical should reside in the histories | |||
:# 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.<br> | |||
: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<br> | * Journals can have an ISSN assigned, as well as an E-ISSN<br> | ||
:ex: http://journals.cambridge.org/action/displayJournal?jid=KER | :ex: http://journals.cambridge.org/action/displayJournal?jid=KER | ||
| Line 8: | Line 34: | ||
:ex: http://journals.cambridge.org/action/displayMoreInfo?jid=KER&type=eb | :ex: http://journals.cambridge.org/action/displayMoreInfo?jid=KER&type=eb | ||
=== | == Technical == | ||
* The [[Property:Homepage]] should not always add a "http"-prefix ... | |||
=== 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.<br> | |||
:ex1: [[Frank Loebe|my homepage]] has a "https"-prefix.<br> | |||
:ex2: I had the editing problem on the [[RuleML 2008]] page, pasting the link into the field. | |||
==== Nice to have ==== | |||
* <span style="color:red">open 13.09.2008</span> edit support for selecting ontology entities<br> | |||
: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.<br> | |||
:(Meanwhile, the listings at [[Special:Categories]] and [[Special:Properties]] are valuable.) | |||
== Integration of Existing Data == | |||
* get Persons, Journals, Conferences etc. from [http://www.informatik.uni-trier.de/~ley/db/ DBLP]<br> | |||
: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 [http://journals.cambridge.org/action/displayJournal?jid=KER] 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. | |||
Latest revision as of 10: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
- Keep only current info as semantic, historical should reside in the histories
- 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
- Journals can have several editors
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
- ideas
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.
- ideas