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

[Lloyd Kvam]

I'm simply passing this on to db-sig since they were not part of the
recipient list.

On Sat, 2005-03-26 at 18:12, Stephen Waterbury wrote:
> 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
> 
> _______________________________________________
> Pycon2005-attendees mailing list
> Pycon2005-attendees at python.org
> http://mail.python.org/mailman/listinfo/pycon2005-attendees
-- 

Lloyd Kvam
Venix Corp.
1 Court Street, Suite 378
Lebanon, NH 03766-1358

voice:	603-653-8139
fax:	320-210-3409
-- 
Lloyd Kvam
Venix Corp