[Pycon2005-attendees] Re: The Database Divide (another country heard from :)

[Stephen Waterbury]

Patrick K. O'Brien wrote:
> ... I thought I'd just follow up with a
> link to a companion paper on Schevo that covers more than I was able to
> in my presentation and includes lots of pretty screen shots and more
> detailed explanations of Schevo concepts:
> 
> http://schevo.org/documentation/reference/current/

Thanks very much for this, Patrick!  I was at PyCon but unfortunately
missed your talk and (maybe not so unfortunately ;) all the relational
vs. odb hooha, except for the thread on pycon2005-attendees, which
has been quite interesting.

Schevo (is that pronounced "skeevo", with a hard "ch", as in
"schema"?) is interesting, but for me the "REST API for Schevo"
is even more interesting!

I have been busy implementing an O-R API on top of PostgreSQL,
and it's similar to Schevo's.  Like your current Schevo work,
I'm using Twisted's web module -- but for xml-rpc.  I plan to
implement PB and/or "JUCE" (sp?) service(s) over the same
underlying logical interface layer RSN.  I use the Twisted
adbapi interface to PostgreSQL, but nothing else from
twisted.enterprise.

I'm going to see if I can implement a Schevo-REST interface
for my repository app.  I may even be able to reuse some of
your Python code -- I use ElementTree for all my XML work.
(Thanks, Fredrik! ... for the thousandth time. :)

IMO Schevo-REST is a good candidate for a standard REST
"Repository API".  (I use "repository" to mean a generalized
persistence service, which could have any kind of backend.)

Such a standard could enable user interface reuse, but also
inter-repository communications and some forms of federation
among possibly heterogeneous repositories.

The latter in particular would likely be of interest to your
"real-world" Navy customers, among others.  DoD customers
typically have zillions of legacy databases (well, 2 or 3 at
least!) that they need to glue together in various ways and
this could provide an elegant wrapping/gluing technique.
The same applies for any large manufacturing outfit -- a.k.a.
"OEMs".  NASA included.  ;)

In preface to the next paragraph, I'll emphasize that I am
*not* a big semantic web (SW) nor UML maven.  I'm interested in
using SW techniques within controlled domains for integration and
interoperability and (down the road) inferencing and "AI"-type
capabilities.  As to UML, some of my customers want to use UML
tools and extend them in some ... uhhh ... interesting ways.

All through your docs of Schevo are concepts of domain classes,
relationships, and such.  These well-established concepts occur
in several industry standards.  I am developing interfaces to
import/export OWL/RDF, UML/XMI, and STEP (ISO 10303) for my app,
mainly to enable interoperability with other tools and apps that
implement them.

One of my points in bringing that up is that Schevo's REST API
document resonates with some high-level SW concepts and RDF/OWL.
I take a naive and minimalist approach to such standards (partly
because I am trying to deal with so many, so I can't afford
to get lost in the details/warts), and IMO the documentation of
a standard REST repository API could actually benefit by
referring to some SW concepts.

A simple mapping of some Schevo REST API elements to
OWL/SW/XSD:

domain ........... 'owl:ontology' (~ schema, in db parlance)
domain name ...... ~ xsd:ns (or prefix, like 'owl', above)
collection ....... a local population of instances of a Class
supplier ......... a Class instance
action/execute ... (no concept in SW ... thank goodness!  but
                   OWL-S [services] is coming ... urg ;)

For one thing, I like the idea of giving a domain
ontology a URI and a prefix.  A globally unique identifier
enables intelligent publishing (the URI doesn't have to be
a URL, but it's nice if it is ;), discovery, importing, etc.

As Tim Peters famously observed:  "Namespaces are one
honking great idea -- let's do more of those!"

I'm working on an OWL import/export interface for my app's
"meta-repository", as one way of publishing its ontology,
importing/exporting and integrating with related ontologies,
etc.  I'll try to make it as independent of the rest of my
app as possible, in case anyone is interested in using it.

A Python ontology module might also be useful.  I have some
of the classes, but they are a bit too tightly coupled to
my app right now -- I need to de-couple them more anyway, so
if anyone thinks it would be useful, I could release it.  I'm
using RDFLib for the import/export (an exception to my use of
ElementTree for XML -- the RDF/XML spec makes me nauseous ;).

Interesting that your example uses the "oid" attribute for
"suppliers" in exactly the same way that STEP (ISO 10303)
identifies (and cross-references) instances within a STEP
file (ISO 10303-21):  integers -- a simple, locally unique
identifier.

BTW, as an indication of just how similar our app domains are,
the "organization" class in my app's core ontology mirrors the
structure of "Commercial And Government Entity" (CAGE), which
is a concept I'd bet money you use in your Navy logistics-related
app.  ;)  If you're interested, I'll send you the ontology, which
I'll be releasing publicly Real Soon Now, anyway.

Sorry it got so long!  Let me know if any of this sounds
interesting.

Cheers,
Steve