RE: problems with concise bounded descriptions

> -----Original Message-----
> From: ext Benja Fallenstein [mailto:b.fallenstein@gmx.de]
> Sent: 01 October, 2004 17:43
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: pfps@research.bell-labs.com; www-rdf-interest@w3.org
> Subject: Re: problems with concise bounded descriptions
> 
> 
> 
> Hi Patrick, hi Peter--
> 
> wow, it certainly looks like there are some communication 
> problems here! 
> ;-) I thought maybe it would help at this point if an 
> outsider steps in 
> and tries to explain where it seems that you don't understand each 
> other. Hope this helps -- sorry if it's just more noise...
> 
> I believe that there are at least two general problems that Peter has 
> with the specification. First, the much discussed paragraph:
> 
>      A concise bounded description of a resource is a body of 
> knowledge
>      about that resource which does not include any explicit knowledge
>      about any other resource which can be obtained 
> separately from the
>      same source.
> 
> Aside from the details you've discussed, the more fundamental 
> issue is 
> that Peter sees this as a *definition* of CBD: i.e., everything that 
> fits this description is a CBD.
> 
> Then, he argues, "always return an empty graph, no matter 
> what knowledge 
> you have" is a procedure that generates a CBD, according to the above 
> definition.
> 
> Seeing the context, I don't actually believe that Patrick meant the 
> above paragraph to be a *definition* of CBD, but just as a 
> description 
> of some traits of CBDs. After all, the document only purports 
> to define 
> "a concise bounded description of a resource *in terms of an 
> RDF graph*" 
> (emphasis mine), and there is an entire section called "Definition."

You may have hit on something there.

The document is, by no means, intended to provide a formal or *mathematical*
definition, but more an informal presentation of the nature of CBDs and
a means to produce them, given a particular node in a particular RDF graph.

> However, *if* the paragraph above was meant as a general definition 
> (independent of the notion of an RDF graph) of what a CBD is, 

It's not. And I think the document is more than clear enough about
being presented in the context of an RDF graph.

> then Peter 
> is right: by that definition, a correct procedure for obtaining a CBD 
> would be to just always use the empty graph, no matter what knowledge 
> you have about a resource; then the notion of "CBD" wouldn't be very 
> useful. *If* the paragraph is intended to define CBD, it 
> would be more 
> useful to refine the definition to make sure that if useful 
> information 
> is known about a resource, it is part of the resource's CBD.

Well, maybe then we can put that first "problem" to bed.

> The second problem that Peter sees is with the actual 
> definition of CBD 
> (you know, the one in the section called "Definition"), which says:
> 
>      Given a node in an RDF graph which occurs as the subject 
> of one or
>      more statements in that graph, the concise bounded description of
>      the resource denoted by that node is the subgraph of statements
>      comprised as follows:
> 
>      1. Include all statements where the subject of the 
> statement denotes
>         the resource in question; and
>      2. Recursively, for all statements included in the 
> description thus
>         far, for all anonymous node objects, include the inverse
>         functional bounded description of the anonymous resource as
>         follows: (...)
> 
> Now, Peter's point is that the server generally cannot know 
> which nodes 
> in the graph "denote the resource in question." However, it is not 
> possible to perform the process as defined above without 
> knowing which 
> nodes denote this resource.
> 
> The obvious fix is to just say "Include all statements where 
> the subject 
> of the statement is the node in question."

This works for me.


> I'm not sure that this is what Patrick wanted, because he 
> could easily 
> have written that. 

I think at one time I did, in an earlier version.

> Perhaps what he meant was "Include all statements 
> where the subject of the statement is *known* to you to denote the 
> resource in question." 

This also works for me. Though, I think restricting it to 
"subjecthood" is cleaner, as it leaves out of scope how one
might use inference to derive one graph from another, taking
into account *known* co-denoation, and use the derived graph
as the focus of CBD extraction.

> [snip]
> 
> However, this complicates the process and doesn't really add much: It 
> assumes that the server has inference capabilities, 

Right. And while it might, it is not central to how CBDs are 
extracted from a particular graph.

> 
> I therefore suggest that it would be sensible to change "resource" to 
> "node" everywhere in the definition (making the appropriate 
> adjustments 
> to the context). I believe this would address Peter's concerns.

That's a fair suggestion.  I'll look at that in more detail.

> I hope that maybe this mail can help a bit. 

I think it helped alot.

> It's a pity to 
> see you guys 
> slipping into flame mode ("Whatever you're smoking, can I please have 
> some?" ;-)) because (it seems from outside) you're not getting your 
> valid points across to each other.

That was evident to me as well. I thank you for your valuable
act of arbitration ;-)

Cheers,

Patrick

Received on Friday, 1 October 2004 15:13:49 UTC