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 > [EMAIL PROTECTED] > 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 _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
