RE: problems with concise bounded descriptions

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Eric
> Prud'hommeaux
> Sent: 01 October, 2004 05:18
> To: Peter F. Patel-Schneider
> Cc: www-rdf-interest@w3.org
> Subject: Re: problems with concise bounded descriptions
> 
> 
> Not being the author, I will address your points to the best of my
> understanding. But I would also like to point out that something like
> a CBD would allow information servers to respond to queries without
> any specific understanding of the queried object.  Clients would be
> able to expect a certain pattern from such queries.  

Right.

> The world would
> be a little bit more communicative and predictable.

Hopefully.

> Client C1 wants to know about a resource R1. Server S1 has some graph
> that involves that R1. S1 will respond with whatever it wants.
> If it knows the type, it will typically respond with an
> application-specfic graph, for instance, a graph that's particularly
> suited to describing a foaf:Person. If it doesn't know how to or care
> to tailor the response, it can send it's notion of a generically
> helpful graph. The annotea server responds with a subject query, that
> is, all the arcs coming from the queried node. Arcs out seemd to be
> more useful than arcs in, and we never had a compelling reason to do
> both. In this sense, the Annotea response is a cheaper but less
> helpful form of a CBD. It worked for our purposes, but a CBD would be
> more helpful in a bNode-laden graph.

CBD can also be considered a more RDF-complete view of
resource-specific knowledge since it includes reifications,
which typically are expressed using bnodes and thus not
otherwise, included in similar "views" where the query 
consists solely of a URI.

> A client programmer that expects either an application-specific
> response or a CBD can more effectively use the returned data. Without
> a convention, different services will respond with their own slant on
> what's helpful. 

Right. And I'm not saying that our particular definition of CBDs
cannot be improved upon, to more effectivley address a broader range
of applications (without becoming equivalent to a full fledged 
general query solution ;-)

The member submission is a snapshot of what we have found extremely
effective for quite some time, in deployed tools and systems.

> An ontologist may choose to respond with any type arcs
> coming from R1, plus a cloud of ontology surrounding those types. This
> information may be helpful for the Protoge user but not the foaf
> crawler. Another app may choose to respond with arcs-in and arcs-out.
> Given no convention, the client programmer must deal with all likely
> responses. With a convention, he/she may expect soemthing at least as
> rich as a CBD, and maybe more, if the server has a special
> understanding of R1. This puts burden on the protoge user to ask a
> special query to get the ontology cloud, but at least the clients
> know what to reasonably expect and code for.

Right.

It's similar to XHTML versus any other XML content model. Not
everyone's needs are met by XHTML, and many folks can use it
as a starting point but need to augment it, but most folks for
most documents get by pretty darn well with XHTML and having 
that common, consistent solution simplifies alot of things
for alot of folks.

So, CBDs won't meet everyone's needs, and many folks will
need something like, but maybe a bit more/different, yet I
think that most folks for most applications will find them
sufficient (if not ideal) and having such a common, consistent
solution will simplify alot of things for alot of folks.

Cheers,

Patrick

Received on Friday, 1 October 2004 12:26:56 UTC