Re: Reflexivity and antisymmetry uses cases?

Hi Holger,

I guess I will turn this around a bit. Why not consider the perceived  
complexity of OWL as a user interface challenge. It seems to me that  
you are making the assumption that a tool needs to expose the user to  
all owl features on the same footing, and so extra features mean  
extra complexity.

But what if, instead, creative work on user interface helped manage  
the complexity. I'll quickly brainstorm a few ideas to give you a  
flavor of what I am thinking.

- Define less complex, but useful, subsets at the tool level. These  
can be designed completely for usability, rather than by some  
complexity criterion. Present customized interfaces and documentation  
for these subsets. For example, some people use OWL to build simple  
taxonomies. Create a simple and visually pleasing interface for doing  
that and that alone.
- Think about how to create domain specific languages that are easier  
to write, and translate into appropriate, but more complex to write,  
OWL.
- Build up a case library of pattern and enable building definitions  
in a more high level building-block manner. Compile such  
constructions to OWL.
- Recognize repeated patterns of usage in a user's OWL file and make  
it easy for a user to create variants of them.
- Mine ontologies on the web for unique constructions. Contact the  
authors to understand the constructions and then build user  
interfaces tailored to explaining and reusing those constructions.
- Investigate iconography/imagery use in the construction of  
relations. Is there a way to convey the meaning of transitivity  
visually, rather than by presenting the word "transitive". Could it  
be indicated by the user gesturally?
- Think about the user interfaces for the more specific domain  
oriented programs you use. What ideas can be borrowed from word  
processors, drawing programs e.g, visio, spreadsheets, project  
planning software, etc.
- Review the recent release of the Fortress language out of Sun  
Research. Are there ideas that could be adapted to enable alternate  
styles of writing ontologies?

It seems to me that there are real opportunities for tool builders  
such as yourself to make major advances over the dominant mode of  
editing ontologies, which I might argue are almost too generically  
form based and present an over-literal view of the textual elements  
of the language.

So: challenge, not crucifixion.

Best,
Alan

p.s. We could discuss these or other user interface ideas on some  
appropriate forum (maybe this one) or privately some time, if you are  
interested.


On Jan 17, 2007, at 5:52 PM, Holger Knublauch wrote:

> The main point I am raising here is: how do we limit what feature  
> should be included and what should rather not be.  Does it depend  
> on the number of potential users of the feature, or whether  
> something is easy to implement, or both?  I am worried that 1.1 is  
> already adding too much, alienating the capabilities of OWL further  
> and further from average users.  On the other hand, it is clear  
> that features like user-defined datatypes would make OWL more  
> attractive to user communities that currently cannot work with  
> OWL.  Perhaps it would be useful if the working group would come up  
> with an informal Use Cases document that illustrates why certain  
> features have been requested (maybe such a list already exists  
> somewhere?).  Other working groups such as RIF even take a use  
> cases list as their first deliverable.
>
>
>> Are you sure for example that in the ontology developped by  
>> Olivier et al..
>> in Virtual Soldier (the Protégé - DARPA project ) they did not  
>> have such
>> things ?
>
> This project was one among hundreds of projects that used Protege.   
> Not every OWL user is creating medical domain ontologies.  I don't  
> remember a lot of requests for something like owl:SelfRestriction  
> on our mailing lists.  Maybe I am wrong.  If I see many more  
> compelling examples, I am easily converted into a supporter of  
> reflexivity and antisymmetry (for me they are actually trivial to  
> implement - this is not the issue here).
>
> BTW: The classes owl:IrreflexiveProperty, owl:AntisymmetricProperty  
> could easily be defined in another namespace outside of OWL 1.1 -  
> if a certain community needs these features then they can define  
> and import their own ontology with these extras.  Ontology editors  
> would handle these types just like any other rdf:Property  
> metaclass.  Yet the new types don't need to bloat the OWL spec and  
> education documents.  Just a thought... feel free to crucify me.

Received on Thursday, 18 January 2007 07:19:55 UTC