Re: CBD - Concise Bounded Description - Member Submission from Nokia

On Thu, Sep 30, 2004 at 08:07:10PM +0200, Alberto Reggiori wrote:
> 
> 
> On Sep 30, 2004, at 7:33 PM, Seaborne, Andy wrote:
> 
> >
> >Member submission from Nokia (Patrick Stickler) that is relevant to
> >discussions about DESCRIBE, bNodes in CONSTRUCT and possibly to 
> >handling
> >containers and collections.
> >
> >
> >    http://www.w3.org/Submission/CBD/
> 
> yes nice Patrick put his CBD work available as W3C Note
> 
> >
> >
> >Notes:
> > * requires IFP processing in the server
> 
> even though IFBD could be harder than simple bNodes-closure, due it 
> requires RDF-Schema / OWL information handy (i.e. 
> owl:InverseFunctionalProperty definitions) when carrying out the CBD of 
> a resource - a bit of a requirement, due that most RDF data and schema 
> (their definitions) still live separately. Unless of course a service, 
> software, decides to hardcode some well know IFPs like foaf:mbox, 
> foaf:homepage and so on.

In real-world problems, both the server and client have an arbitrary
amount of knowldege about the schema. The server may send the client
IFPs that the client doesn't know are IFPs. Likewise, the server may
send some arc that the only the client knows to be an IFP. CBDs should
be evaluated as a compromise between terseness and completeness.

A client C1 sends a query Q1 to a server S1. The response involves
resource R1. The recipe is pretty strait-forward ([1] has some
pictures of the product):

  Include all arcs out of R1.

  Include all arcs from rdf:Statements that involve R1.

  For each object that is a bNode, identify it by an IFP, if
  known, or do a recursive CBD traversal starting from that node.

IFP processing is only used on the involved bNodes. If neither S1 or
C1 know that a property is an IFP, it doesn't matter that it's an
IFP. If S1 knows but C1 doesn't, C1 gets a bNode dscription that it
can use to constrain subsequent queries, but it doens't reallize it
can use to unify nodes. If C1 knows but S1 doesn't, C1 gets a more
verbose description of the node than it needed.

So IFP processing isn't *needed*, but it's nice if both the client
and the server happen to do it and recognize some of the same IFPs.

> Anyway, such issues should not affect DAWG definition of  DESCRIBE, if 
> we pretend it to return an implementation (protocol?) specific 
> sub-graph containing information about the resource being described 
> I.e. the same DESCRIBE request might return different results from 
> different services.

If we decide to define "bNode closure", I'd rather start with CBDs. If
we stay with return-what-you-want, I'd like to non-normatively suggest
CBDs so that service developers don't have to guess a starting point
and client's will often get consistent data. That is, I'd like
everyone who doesn't already have a preference to consider CBDs.

> > * includes the reification of any included statements
> 
> return all statement reifications might also be painful...perhaps 
> should that be optional or negotiable?

I asked Patrick about this [2 look for "Problem 6:"]. He mentioned
them in passing in a later post [3 look for RDF-complete]

[1] http://www.w3.org/2004/09/22-CBD-Comment*,access*
[2] http://lists.w3.org/Archives/Public/www-rdf-interest/2004Oct/0000
[3] http://lists.w3.org/Archives/Public/www-rdf-interest/2004Oct/0013
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.