Re: Contexts (was Classes vs. Instances)

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

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