Re: top-3's received so far

My top 3 are aimed at helping someone who has not really used SW or 
ontologies (or maybe just a little) but has heard it's a good idea 
and comes to all this  trying to figure out who he can make use of 
it. I believe that in large part the materials produced by the 
working group will be addressing these types of folks.

1. Write an OWL Development Guide: What I am thinking is some sort of 
a hybrid of the OWL Guide and Ontology Development 101: a document 
that concentrates on modeling rather than language features (but 
modeling for OWL), and talks about modeling examples, good and bad 
ways to do things, common pitfalls (e.g., parts shouldn't be 
subclasses, synonyms shouldn't be different classes, etc.), answers 
to common questions (should I make this a class or an instance, when 
should I use allValuesForm vs someValuesFrom), and rules of thumb.

1a (it's really closely part of 1, but permeates other things that 
we'll do) Get away from angle brackets: If we are aiming at wide 
adoption of OWL, we shouldn't really expect people to learn to read 
OWL Syntax to understand all the FAQ's, how-to-guidelines, etc. that 
we produce under  Focus Area 2 (see WG charter). I think developing 
some sort of conventions for showing snippets of OWL that don't have 
to be very formal but are easy for most people to understand 
(diagrams a-la UML diagrams? screenshots from OWL GUI editors? 
something else?) would lower the adoption threshold for a lot of 
people. I am not advocating developing another abstract syntax that 
would be easy to read, rather just a set of conventions that we can 
use in our FAQ's, how-to-guidelines, explaining design patterns, 
describing examples, etc.

2. Explain the differences between RDF, RDF Schema, XML Schema, OWL 
Lite, OWL DL, OWL Full, UML, etc. Help someone who is new to all this 
stuff and finds all these different standards figure out which one is 
write for him. Perhaps a set of suggestions along the lines of "If 
you need to do only X and Y than Z will work well. But if you want to 
do XX and YY, you have to go with ZZ.  The X's and Y's have to be 
practical things that people need to do.

3. Create a catalog of SW tools which not only categorizes them 
according to what they do, but also gives people some sense of how 
good they are, or perhaps who are they good for (e.g., if you are a 
logician and are comfortable with formal concepts, A is a tools for 
you; if you are willing to sacrifice some expressiveness for not 
having to deal with complex formalisms and interfaces, go for B"). It 
may be hard to categorize tools as good or bad, but this more 
usage-oriented categorization may work.

Natasha

Received on Wednesday, 3 March 2004 13:24:33 UTC