OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [Fwd: Potential Gap (WAS Re: [owl-s] communication between

[ Lists Home | Date Index | Thread Index ]

Hi Len,

I should be clearer: I was actually thinking of a different type of
querying than ad hoc. I see ad hoc querying (as you know) as a type of
query in which the queryer (is that a word?) is presented with a user
interface (such as a portal) that may present drop-down lists of various
category values (based on a set of taxonomies) from which they select,
or use some type of textual query, etc. In such cases, there is full
knowledge of the database schema by the entity that is requesting the
information (e.g. the application code or ad hoc query tool behind the

My example was one in which the request for information (the additional
needed information) was made by an entity (the Hotel Reservation Web
Service) that had no knowledge whatsoever of the "source" database
schema - it just knows that it is missing information that it requires.
So it seems to me that we may need some mechanism for an entity to
communicate a request for information it needs to another entity in a
standard mechanism, so that there is complete understanding between the
2 entities. Of course, the Travel Agent Web Service should be fully
aware of the source database schema - so as long as it fully understands
the request from the Hotel Reservation Web Service, it should be simple
for the Travel Agent Web Service to query the source database for the
needed information information. Now that I think about it more, a
semantically aware database may not be necessary in this case - as long
as there is sufficient semantic understanding between the requestor
(Hotel Reservation Web Service) and requestee (Travel Agent Web

However, there may be cases in which such a database may be valuable -
let's suppose that there is a sufficient level of trust between a
requestor and a semantically aware database, but an insufficient level
of semantic understanding (as if the Hotel Reservation Web Service made
a direct request to the source database in the example I've given). This
is a case where such a database may be valuable, so that the requestor -
which has no knowledge of the database schema - can request information
from the database and receive exactly what it was looking for.

In closing, it looks like this could be a single mechanism to me - but
applied to different types of entities (Web Services, databases, etc.).

Kind Regards,
Joe Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World

"Bullard, Claude L (Len)" wrote:
> Unless one is say, creating ad hoc SQL queries and sending them
> to a non-collocated database, why would deep schema information
> be necessary?  I don't think many private holders of data will
> be too eager to expose all of the local schema information but
> they would be willing to negotiate services that equal reports.
> It is completely possible to expose the schema or to expose
> an interface schema that middleware then transforms into
> the local schema.  As you say, Thomas, mappings.  BTW, why would I
> need OWL to implement what is essentially a business object?
> I don't see the problem.  What am I missing?
> Joe, you may be asking for ad hoc querying.  If so, it is
> doable but not often done for external resources.   Crystal
> Reports and ODBC make it possible.  The trick, as you note,
> is that given a flat set of descriptions without the integrity
> information, the security objects, etc., it is hard to build
> a good query and easy to screw up a database if the ODBC
> connection is badly configured.  For that reason, the service
> should provide the right codes and relationships for its
> set of queries available by the role of the authorized and
> authenticated querying agency.   NCIC for example, has a
> set of standard queries.
> len
> From: Thomas B. Passin [mailto:tpassin@comcast.net]
> Chiusano Joseph wrote:
> > I sent this e-mail over 24 hours ago to the W3C Semantic Web Services
> > Interest Group, and I did not receive any pushback (a gentle way of
> > saying I did not receive a reply ;). So I'm wondering if that is good or
> > bad....
> > Here is a scenario:
> > ...
> >
> > At this point, we need the following to happen:
> >
> > (1) The Hotel Reservation Web Service must relay to the Travel Agent Web
> > Service the information that is missing, and
> > (2) The Travel Agent Web Service needs to obtain that missing
> > information from the Travel Agent relational database
> >
> > It is #2 above that I perceive as a current gap - i.e. unless the Travel
> > Agent relational database is sufficiently "semantically aware" (i.e.
> > perhaps it implements an OWL ontology whose classes and properties are
> > mapped to the database tables/fields respectively), there is no
> > efficient and accurate way that the required information can be obtained
> > from the Travel Agent relational database.
> > </Scenario>
> >
> This seems to be no different from any other data integration problem.
> In general, it is impossible to automatically map from one database
> schema to another, because most databases do not/cannot contain enough
> explicit schema and ontology information to do so.  In many if not most
> cases, people will have to create the mapping, or at least to adjust an
> automatically-obtained mapping.  If not a map, then a wrapper to make
> the database respond like, say, and rdf database.
> This is one reason I have never believed in the practicality of fully
> automated service composition (or fully automated web service discovery,
> for that matter, and for similar reasons).  But if you say that the
> agents are only to operate within known domains, the mappings or
> wrappers could be prepared in advance, just as is done today.

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS