- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Tue, 23 Sep 2008 09:14:08 -0400
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: public-owl-wg@w3.org, "Robert Stevens" <robert.stevens@manchester.ac.uk>
- Message-ID: <29af5e2d0809230614n10b2e52g797308cff55a503@mail.gmail.com>
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