|
Leo,
Responses in line below.
> From: "Obrst, Leo J." <lobrst@xxxxxxxxx>
> To: OpenOntologyRepository-discussion <oor-forum@xxxxxxxxxxxxxxxx>
> Date: 05/09/2012 05:13 PM
> Subject: Re: [oor-forum] OOR UI issues
> Sent by: oor-forum-bounces@xxxxxxxxxxxxxxxx
>
> Ken, some comments below.
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: oor-forum-bounces@xxxxxxxxxxxxxxxx [mailto:oor-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of kenb
> Sent: Tuesday, May 08, 2012 10:30 PM
> To: OpenOntologyRepository-discussion
> Subject: [oor-forum] OOR UI issues
>
> During the most recent OOR Architecture & API Workshop, questions were
> raised concerning what UI is most appropriate for the OOR requirements. We
> are soliciting comments and suggestions about this issue from the OOR
> community, especially from individuals who have UI development and testing
> experience.
>
> Here is a brief summary of some of the issues that were raised:
>
> The top of every page of an OOR website consists of a row of links (tabs).
>
> 1. Is this the most appropriate UI?
>
> [Leo: ] I guess we have this GUI primarily because of the BioPortal
> antecedents? And of course Protégé.
--->>> Yes.
> Tabs in Protégé always were a kind of signal to me that behind the
> tab was a potentially independently developed plugin. Is that still
> roughly the same?
--->>> Yes. The intent is to have the UI decoupled from the services
provided.
> It also therefore meant that you could configure
> your GUI by either downloading plugins at or after installation and
> then making them active, inactive.
--->>> Probably. First, the term we've been using is modules, as in
modules of functionality. Whether they'd behave in a true plugin
was is yet to be seen (i.e., dynamic self configuration).
Currently the plan/architecture would have language modules,
together with core or common service modules.
> [Leo:] Is this the anticipated semantics for the OOR plugins?
--->>> Sort of. See the previous response above.
> If not
> (or even if), then we might keep this because of background shared
> user knowledge. Otherwise, a menu-like list of sub-descriptions and
> actions (like under the more generic browsers, e.g., Firefox) might
> be useful. My thought is if the tab-space gets crowded over time,
> indeed you can have banks of tabs, but if each tab had distinct
> services or views, you might want a drop-down menu so you could
> select a more specific service or view under the particular tab.
--->>> As has been demonstrated with Michael's COLORE work, there
are implicit assumptions that are coupled to the way one
has become familiar with when working with OWL and RDF(S)
they are not valid in general.
> 2. Should every page have the same set of tabs?
> [Leo: ] Maybe not, except for some core tabs.
--->>> Yes. A similar term might be 'common' tabs (that represent
core functionality common across all language modules).
> 3. If tabs can vary, should there be a core set of tabs followed by the
> varying tabs?
> [Leo: ] I would say "yes", so that people know what the core set is.
> They will learn this via interaction over time, but for new users,
> the readily identified distinction could be useful.
--->>> Agreed. To facilitate use of the OOR across different languages
a common core set of operations is needed.
> 4. What tabs should be in the core?
> [Leo: ] I'm not sure, but one question: I assume "Browse" is to see
> the ontologies.
--->>> I think there was agreement that 'Browse' and 'Search' are
common/core across all language modules. Mappings, which
currently is a variation of search, is another.
> Is there a way to see the services that people have
> provided?
--->>> Why might this capability be needed?
> I understand that basically we are using BioPortal as
> much as possible, i.e, http://www.bioontology.org/wiki/index.php/
> NCBO_REST_services. Are we wedded to that?
--->>> The expectation is that there will be a co-evolution, but at
some point the divergence will begin.
> 5. Should the tabs vary depending on the role, page and OOR instance?
> [Leo: ] Probably the tabs will vary based on role and also by OOR
> instance (if the instance e.g., uses extensions).
--->>> Agreed. Depending on the deployment situation role based access
maybe a requirement, while in others it may not. We'll need
to develop a way to control the deployment.
> By page? I'm not
> sure. I would consider a functional notion like role, etc., as a
> rationale for the variation at a page, i.e., what kind of page?
--->>> Possibly by page. What kind of page, I'd might suspect pages
associated with different language modules.
Todd
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (01)
|