Re: Contexts (was Classes vs. Instances)

["Rich Cooper" <rcooper15@comcast.net>]

Avril Styrman wrote:

> 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.

Respectfully, every table and view in an SQL database is a type (class) 
definition.
Tables define a set of properties (columns) to be associated with each 
instance (row)
of the type (class).  Domains define the legible nature of each property 
(column).
Views, which can be derived from any table, can easily handle the 
Person>Employee
type subset you used as an example.

> 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?

Any frame can be implemented as a view, perhaps of multiple tables.  To use
multiple types (classes) in a frame, simply combine the tables with the 
proper
join expressions and zot - you have a frame.

When the industry found out that relational SQL databases were so useful,
people naturally jumped to the conclusion that object-oriented databases 
could
go yet one better by adding types of a higher level of abstraction.  As you 
may
have noticed, it didn't work.  That's because object-oriented programs use 
stacks
to keep the objects straight, but persistent storage systems like SQL don't 
have
any use for stacks, except in stored procedures, where they are dynamic data
structures, not persistent tables.

So what exactly could be added to SQL to make types any more useful there
than the standard tables, views and procedures?

IMHO, SQL has reached its major advances already.  More built in functions,
a little improvement in domains (blobs should already have been supplemented
with JPEGS, files, even databases as domains, but for some reason this 
hasn't
happened yet).

If anyone can suggest an improvement to SQL in detail, I would be very
receptive.

Rich

> 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
>