Re: Contexts (was Classes vs. Instances)

[Avril Styrman <Avril.Styrman@helsinki.fi>]

Hi, 

it is good to always comment code properly. RDFS is so simple that it can be
understood without commenting, but in OWL there might be so complex stuff
that it needs to be explicitly commented. But I can't see how even very
pedantic natural language could be automatically translated into logic.
Maybe you meant that if you have an ontology that has e.g. a very complex
sequence definition, then it is easier to use it if the semantics of the
sequence definition is explained with natural language. But, even simple
RDFS is so hard (also for professional Sun-qualified Java programmers) to
use that I expect more complex OWL to be even a lot harder. With small
applications it is a lot faster to just type the words in the Java code
instead of using an ontolgy. 

describing things with that framework takes too much resources

Arvil 


Quoting Rolf Schwitter <rolfs@ics.mq.edu.au>:

> Hi Avril
> 
> >Do you have a clear idea of the syntax of some better language than RDFS
> or 
> >OWL?
> 
> I came across the following paper:
> 
>     http://www.co-ode.org/resources/papers/ekaw2004.pdf
> 
> One guideline there is
> 
>     "Always paraphrase a description or definition before encoding it in
> 
> OWL, and record the paraphrase in the comment area of the interface."
> 
> If it is possible to paraphrase a description or definition first "in 
> pedantic but explicit language", then I don't see any need for any
> further 
> (intermediate) formal encoding.
> 
> This "explicit language" could directly be translated into whatever the 
> available (description logic) reasoner digests.
> 
> Cheers,
> Rolf
> 
> 
> > Hi,
> >
> > it is certainly odd that they did not accommodate type hierarchy
> > even though it was suggested, and very odd that it has not yet been
> > done(?). It must be the fallibilism. Just think how many hours are
> > wasted every day in figuring out the meaning of some SQL tables, and
> > how many hours less would be wasted if SQL had the type hierarchy.
> > It is anyway good to know that people do have suggested it so early.
> >
> > Even though tens of thousands have lived very long with SQL without
> > types, moving into types would not be hard for them. It is clear
> > that a type hierarchy _editor_ for standard SQL could be built yet
> > not changing SQL in any way. If they now have tables PERSON and
> > EMPLOYEE, these could be set into a hierachy PERSON > EMPLOYEE by
> > adding only one property for the tables: subcategoryOf, that has
> > the universal type as a default value or no default value at all,
> > and making one rule: the subcategories inherit all the fields from
> > their supercategories.
> >
> > Frame-based ontology editors can export many languages. Do you have
> > a clear idea of the syntax of some better language than RDFS or OWL?
> >
> > Avril
> >
> >
> >
> >
> > -----------
> > Ocham's razor challenge of the day: Are instances needed at all?
> >
> > Ontology editors basically have classes, properties, and instances.
> > One great simplification would be to totally discard instances. E.g.
> > in Protege classes can anyway have all the same values for properties
> > than instances, and subclasses can be considered as instances of
> > their superclasses. I cannot think of an example where the dividition
> > to especial instances, and to classes is required. A proof: there is
> > no need for a type hierarchy of instances because there is already a
> > hierarchy of classes. E.g. Protege turns all super-instances into
> > classes anyway if one loads an RDF Schema that does have
> > super-instances. Therefore instances can be only the leaves when the
> > ontology is considered as a graph. The leaves can be easily turned
> > into classes. Try different schemas, and discover that instances
> > are not required. Or are they, why?
> >
> >
> > Quoting "John F. Sowa" <sowa@bestweb.net>:
> >
> >> AS> ...  It is easier for a normal person to create an ontology
> >>  > with a frame-based ontology editor than by using SQL tables.
> >>  > Sure, the idea of frames existed long before SemWeb, but after
> >>  > working with a large and messy SQL database for two long years,
> >>  > I would welcome a frame-based SQL editor. That would surely help
> >>  > to build and to use a database, since SQL databases are (imho)
> >>  > very much easier to apply than RDF databases.
> >>
> >> I certainly agree with the two main points:  SQL does not have
> >> good tools for supporting a type hierarchy, but SQL databases
> >> are far easier to use than RDF databases.
> >>
> >> But you don't need frames or RDF for a good type hierarchy.
> >> Aristotle developed that over 2300 years ago, and Porphyry
> >> developed tree diagrams for representing type hierarchies
> >> over 1700 years ago.  Ted Codd and Chris Date were arguing
> >> for years that SQL should support types.
> >>
> >> I blame IBM and Oracle for the weaknesses of SQL.  First,
> >> IBM is to blame for not adding types, which were being
> >> discussed by many people (including me) within IBM during
> >> the 1970s.  My first published paper on conceptual graphs
> >> in 1976 proposed CGs as a schema language for RDBs:
> >>
> >>     http://www.jfsowa.com/pubs/cg1976.htm
> >>
> >> Second, I blame Oracle for implementing the first version
> >> of SQL that had been published in the IBM Journal of R & D
> >> instead of the much better QUEL language that Stonebraker
> >> had developed for Ingres.
> >>
> >> AS> SemWeb languages have at least two good features: they
> >>  > are frame-based and they are easily shareable. I'd be better
> >>  > off with SQL that would accommodate these two features. Then
> >>  > again the errors of RDF appear while one is trying to use
> >>  > an RDFS ontology by working with e.g. JENA. It is slightly
> >>  > amusing, but mostly painful.
> >>
> >> I agree.  There's an old saying,
> >>
> >>     Those who don't know history are doomed to reimplement it.
> >>
> >> John
> > 
> 
> 
>