Re: Manchester Syntax document ready (ACTION-205)

On Tue, Sep 23, 2008 at 6:29 AM, Peter F. Patel-Schneider <
pfps@research.bell-labs.com> wrote:

> From: "Alan Ruttenberg" <alanruttenberg@gmail.com>
> Subject: Re: Manchester Syntax document ready (ACTION-205)
> Date: Mon, 22 Sep 2008 22:56:08 -0400
>
> > On Mon, Sep 22, 2008 at 7:45 PM, Peter F. Patel-Schneider
> > <pfps@research.bell-labs.com> wrote:
> > > I don't know what you are asking for here.
> > >
> > > It is true that annotations interfere with the flow, and thus make
> > > ontology dumps hard to read, but what else can be done?
> >
> > The issue is not the annotations but rather the display of any entity
> > that does not use a human readable URI.
>
> But how then can the Manchester syntax help?  Do you want to have a
> "dump" of an entity not use its URI?  That doesn't seem to allow
> reloading.  I don't see what role the Manchester syntax has to play here
> at all.


One goal of the Manchester syntax  is that it be possible for visually
impaired people to read an ontology using a screen reader. The first test of
this is that it can be effectively read by a sighted person. At the moment,
for a significant set of ontologies, it can not.

In order to be enable to reloading the ontology the annotation associating
the URI with the label should remain intact.

> > I will change the "user-friendly" bit to talk explicitly about
> > descriptions.
> >
> > I'd rather live up to the "user-friendly". The implementation of
> > Manchester syntax in Protege allows the use of a label in place of a
> > localname in expressions.
>
> Sure, and that is very nice, and a very useful feature for user tools.
> But, again, what role does a syntax for OWL 2 have to play here?


See above. We don't need another syntax for OWL unless it serves a purpose
above and beyond what the other syntaxes do.

> The first thing I would suggest is a syntax for comments that can be
> > embedded by tools.
> > "//" "#" "/* .. */" ";" are common convention, but "( .. )" fit in
> > some spots.
> > With this a tool would be able to write, e.g.
> >
> > Class: obo:artifact
> >     Annotations:
> >        obo:IAO_0000116 ( editor note ) "There is not yet consensus this
> term",
> >        obo:IAO_0000114 ( curation status ) obo:IAO_0000124 ( uncurated ),
>
> > The next level of change would allow, in the case that a rdfs:label
> > uniquely determines the identity of a term, a tool to use the
> > rdfs:label in place of the uri ref.
> >
> > Class: obo:artifact
> >     Annotations:
> >        'editor note': "There is not yet consensus this term",
> >        'curation status': 'uncurated',
>
> This might be nice for display, and it is certainly useful to do in user
> tools, for example when displaying an entity interactively, perhaps even
> when the label is not unique.  However, to use this in dumps of ontologies
> seems to be rather tricky.  What happens if the ontology is hand-edited
> to remove a label used in this way, or to remove its uniqueness?


The same thing that happens when one hand edits any other file and makes a
mistake - one gets a damaged file.


> Do you really want a syntax, even a syntax that is designed to be
> user-friendly, to have to consider these sorts of things?


Yes. Otherwise I would not have written in the first place.


> There is nothing to prevent tools from adding precisely these sorts of
> extensions, and no interoperability concerns if these sorts of
> extensions are solely used for display.


Absent a comment syntax a tool can not embed any extra information in a
Manchester Syntax file. This is what motivated my first request.

-Alan


> > Where the label is not unique it could be qualified by the uri
> >
> > Class: obo:artifact
> >     Annotations:
> >        'editor note' (obo:IAO_0000116) : "There is not yet consensus this
> term",
> >        'curation status': 'uncurated',
> >
> > In the case that there are multiple language labels, we could leave it
> > to the discretion of the tool to provide a mechanism for choosing a
> > preferred language.
>
> > -Alan
>
> peter
>

Received on Tuesday, 23 September 2008 13:14:43 UTC