[seek-kr-sms] GrOWL -metadata panel design.

[Bertram Ludaescher]

I don't know how easy/meaningful this is, but maybe there can be a
switch "ns on/off".

Bertram

Rich Williams writes:
 > While I appreciate the desire for simplicity, I don't think the issue of
 > namespaces can be entirely avoided, though it can and should largely be
 > buried and hidden from the average user.  I think the issues are more
 > present when editing an ontology than when browsing, but even when browsing,
 > namespace prefixes might be necessary to accurately disambiguate concept
 > names.  To completely suppress namespace prefixes is essentially adding a
 > more stringent naming requirement than currently exists in OWL.  It would
 > require that names be globally unique, rather than just unique within a
 > namespace.  If GrOWL is to be a general purpose ontology browsing and
 > editing tool, this requirement cannot be enforced, and so some level of
 > namespace exposure is inevitable.  Of course it shouldn't be something
 > staring the first-time user in the face, but I think it does need to be
 > dealt with.
 > 
 > Remember also that Serguei was asking about the UI for ontology metadata in
 > general, not just about the UI for imports and namespaces.  Even if
 > namespaces are not exposed, there still needs to be a UI (panel/dialog/tab)
 > for this other metadata.
 > 
 > Rich
 > 
 > -----Original Message-----
 > From: seek-kr-sms-admin at ecoinformatics.org
 > [mailto:seek-kr-sms-admin at ecoinformatics.org]On Behalf Of Matt Jones
 > Sent: Monday, June 28, 2004 12:28 PM
 > To: Shawn Bowers
 > Cc: Serguei Krivov; seek-kr-sms at ecoinformatics.org
 > Subject: Re: [seek-kr-sms] GrOWL -metadata panel design.
 > 
 > 
 > I have to agree with Shawn -- our end users really should not be exposed
 > to technical details such as namespace URIs and similar constructs at
 > all.  If unique namespace URI's are needed, Growl should be generating
 > and tracking them for the user.  They'll have a hard enough time
 > wrestling with just the ecological concepts in a formal manner. So I
 > would add #4:
 > 
 > #4: No namespaces exposed in GUI whatsoever
 > 
 > Matt
 > 
 > Shawn Bowers wrote:
 > >
 > > I am not entirely sure what you are asking. If you could craft up some
 > > screen shots of what you are thinking that would really help.
 > >
 > > My general opinion is that namespace names are useful (if people
 > > organize ontologies around these), namespaces (as URIs) for people to
 > > view are not and shouldn't be integrated into the graphical interface.
 > > If someone really wants to see them, then I would suggest using a
 > > different window (for "expert" mode) that lists namespace names and
 > > their corresponding URI.
 > >
 > > Also, how do you see people using namespaces in your editor? How are you
 > > going to present them to a user in terms of modeling constructs? E.g.,
 > > are you going to view each namespace as an "ontology"? Are there
 > > operations you are planning on supporting over namespaces (like get all
 > > concepts from a namespace)?
 > >
 > >
 > > Shawn
 > >
 > >
 > > Serguei Krivov wrote:
 > >
 > >> Hi All,
 > >>
 > >> We are getting close to graphic editing support for main owl
 > >> constructs- this was a difficult part. Now we can also think about
 > >> easy things like icons for editing toolbox and  editing metadata for
 > >> ontologies.  The later point however brings certain hard questions.
 > >> Metadata pane should contain comments, author information and
 > >> namespaces-imported, default etc. If authors info and comments could
 > >> easily go into one more side panel,  it may be not so easy with
 > >> namespaces. There are at least 3 options:
 > >>
 > >>
 > >>
 > >> #1 Put namespaces on side panels. Pros –easy to make, cons- namespaces
 > >> will be wrapped since they need long field
 > >>
 > >> #2 Put namespaces on popup dialog. Pros- easy to make, cons –not
 > >> aesthetically appealing
 > >>
 > >> #3 Create tab panel. One tab contains present view , another contains
 > >> metadata view. Pros- aesthetically appealing, cons – perhaps may
 > >> require more work.
 > >>
 > >>
 > >>
 > >> Would you please vote or give your suggestions. Any better option (#4,
 > >> #5,
)
 > >>
 > >>
 > >>
 > >> Thanks,
 > >>
 > >> Serguei
 > >>
 > >>
 > >>
 > >>
 > >>
 > >>
 > >>
 > >
 > > _______________________________________________
 > > seek-kr-sms mailing list
 > > seek-kr-sms at ecoinformatics.org
 > > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
 > 
 > --
 > -------------------------------------------------------------------
 > Matt Jones                                     jones at nceas.ucsb.edu
 > http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
 > National Center for Ecological Analysis and Synthesis (NCEAS)
 > University of California Santa Barbara
 > Interested in ecological informatics? http://www.ecoinformatics.org
 > -------------------------------------------------------------------
 > _______________________________________________
 > seek-kr-sms mailing list
 > seek-kr-sms at ecoinformatics.org
 > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
 > 
 > _______________________________________________
 > seek-kr-sms mailing list
 > seek-kr-sms at ecoinformatics.org
 > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms