Re: problems with concise bounded descriptions

From: <Patrick.Stickler@nokia.com>
Subject: RE: problems with concise bounded descriptions
Date: Fri, 1 Oct 2004 16:21:32 +0300

> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider 
> > [mailto:pfps@research.bell-labs.com]
> > Sent: 01 October, 2004 15:50
> > To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> > Cc: www-rdf-interest@w3.org
> > Subject: Re: problems with concise bounded descriptions
> > 
> > 
> > From: <Patrick.Stickler@nokia.com>
> > Subject: RE: problems with concise bounded descriptions
> > Date: Fri, 1 Oct 2004 14:18:41 +0300
> > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: www-rdf-interest-request@w3.org
> > > > [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Peter F.
> > > > Patel-Schneider
> > > > Sent: 01 October, 2004 02:40
> > > > To: www-rdf-interest@w3.org
> > > > Subject: problems with concise bounded descriptions
> > 
> > [...]
> > 
> > 
> > > > The notion of Concise Bounded Descriptions (CBD) in this note 
> > > > has a number
> > > > of problems.
> > > 
> > > No doubt. I'm always keen to fix problems.
> > > 
> > > > The initial description of a CBD is severely underspecified.  
> > > > According to
> > > > the note, ``A [CBD] 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.''
> > > > 
> > > > Problem 1:  Which source?
> > > 
> > > The source of statements (graph) from which the CBD is 
> > being extracted.
> > 
> > OK, but why is this not stated here?  
> 
> [[
> This document defines a concise bounded description of a resource in terms of an 
> RDF graph, as an optimal unit of specific knowledge about that resource to be 
> utilized by, and/or interchanged between, semantic web agents.
> ]]
> 
> [[
> A concise bounded description can be defined in terms of an RDF graph as follows:
> 
> Given a node in an RDF graph...
> ]]
> 
> 
> I'm not quite sure how I could be more explicit...

Yes, I wasn't looking at the larger context here.

> If you would like to offer better/clearer wording, I'd be happy
> to have your suggestions.


> > > > Problem 2:  What is ``explicit'' knowledge?
> > > 
> > > As in "information which is explicit and formally defined", i.e.
> > > not in the mind of some human or expressed in a manner, such
> > > as using natural language, which requires a human to interpret
> > > to figure out, and may give rise to ambiguity, but rather 
> > > "expressed in a machine understandable language" such as can
> > > be used by automated semantic web agents.
> > 
> > OK, this is a good definition of explicit, but why is this not stated?
> 
> 
> [[
> ... semantic web agents (at present at least) are not able to deal as 
> well with the broad range of possible representations which might be 
> associated with a resource; and in nearly all cases, are unable to make 
> any use of such representations, as they are typically intended for human 
> rather than machine consumption. Semantic web agents, not being anywhere 
> near as intelligent as most humans, require information which is explicit 
> and formally defined. In short, semantic web agents need concise, bounded 
> descriptions of resources, expressed in a machine understandable language, 
> rather than seemingly arbitrary representations which to agents are usually 
> semantically opaque. 
> ]]
> 
> Again, I'm not sure why that doesn't work for
> you, but again, feel free to suggest alternate
> and/or additional wording.

It doesn't work because ``explicit and formally defined'' doesn't tell me
what ``explicit'' means.  The ``i.e., ...'' that you added, indicated to
tell me that explicit just means formally represented.  

> > Also, this clarification of ```explicit'' exposes further problems.
> > 
> > Consider the RDF graph consisting of a single statement
> > 
> > 	ex:a ex:r ex:b .
> > 
> > Why is this statement not ``explicit kowledge about [another] resource
> > which can be obtained separately from the same source''?  There is no
> > reason not to postulate that the source cannot answer questions like
> > ``return all the triples with ex:b as the object''. 
> 
> CBD makes no such presumption. The same source (agent) may respond
> to all kinds of requests expressed in all kinds of manners, including
> more general queries asking e.g. 
>
>    ``return all the triples with ex:b as the object''
> 
> I don't see how that has any direct significance to the CBD spec.

It most certainly does.  You state

	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.

If you define ``explicit'' as ``formal'' and allow queries like

    ``return all the triples with ex:b as the object''

then 

	ex:a ex:r ex:b .

is ``explicit knowledge about [another] resource which can be obtained
separately from the same source'', e.g. by the above query.


> > > > Problem 3:  What is ``obtain separately''?
> > > 
> > > By separate request/query.
> > 
> > OK, but why is this not stated here?
> 
> Because I wrote that part of the spec on a Thursday, and I *never*, 
> absolutely *never* write the word "request" on a Thursday (and
> when Friday rolled around, I forgot to go back and fix it... ;-)



> > > > Problem 4:  A function that always returns nothing satisfies this
> > > > description, as it certainly does not include any knowledge 
> > > > (explicit or
> > > > not) that be obtained (separately or not) from the same 
> > > > source (or indeed
> > > > any source at all).
> > > 
> > > I'm sorry. I don't see your point here.
> > > 
> > > If the agent recieving the request knows nothing about the
> > > resource in question, then returning an empty graph is a 
> > > pretty clear indication of that.
> > 
> > The point is that according to your rules, as expressed in 
> > your initial
> > description of a CBD, my process is in every way better than yours.
> 
> And what process is that???

The process defined by the function above.

> > First, my process actually satisfies your initial description of a CBD
> > whereas your does not.  Second, my process is optimal in that 
> > it returns
> > the minimum CBD, whereas you don't give any criteria for 
> > determining the
> > optimally of your process.
> 
> I have working, deployed code that demonstrates its utility.

And how is optimality in any way related to utility?

> > > > The definition of CBD in terms of a procedure on RDF 
> > graphs also has
> > > > serious problems.
> > > 
> > > If it does, then for sure, those should be addressed.
> > > 
> > > > Problem 5:  Given a node in an RDF graph, there is no 
> > general way of
> > > > determining which nodes in the graph are co-denotational with 
> > > > that node.
> > > 
> > > Hmmmm.. isn't that what owl:sameAs is for?  
> > 
> > Not at all.  owl:sameAs tells you that two nodes in a graph are
> > co-denotational.  However the absence of owl:sameAs does not 
> > tell you that
> > two nodes in a graph are not co-denotational.
> 
> And black is black and white is white. 
> 
> > Consider the following RDF graph:
> > 
> > 	ex:a ex:r ex:b .
> > 
> > Are ex:a and ex:b co-denotational?  
> 
> How could I know? How could an agent in possession of
> the above knowledge know? How is this the least bit
> an issue for the CBD definition?

My precise point is that you can't know.  However, your process for
determining the CBD of a node in a RDF graph requires that you determine
whether two nodes are codenotational, which means that your process can't
be performed.

> If the agent *somehow* knows that ex:a and ex:b are
> co-denotational, then any inquiries about either ex:a
> or ex:b should return comparable CBDs. But if it doesn't
> know, it doesn't know. Period. How can it tell you
> something it doesn't know.

This is not what you state in your definition of CBD.  You state ``subject
of the statement denotes the resource in question'', not ``subject of the
statement is not know to denote the resource in question'' a very different
situation.

> Quick, tell me, what color are my socks?! What? You
> don't know? Well then you must be broken, or stupid
> or something...

Thanks for this very insightful comment.  

> And yes, I agree, for me to suggest, or even think such
> a thing is quite unreasonable, unfounded, and I should
> be ashamed. Sorry ;-)

Yes, you should be.  Very sorry indeed.

> > > There is no reason why an agent cannot employ inference when
> > > responding to a request for a CBD -- and in fact, this is 
> > > precisely what the Nokia Semantic Web Server does, though
> > > not full OWL inference (yet).
> > 
> > Irrelevant, see above.
> 
> ???
> 
> > > The graph from which a CBD is extracted, can be one which
> > > contains inferred statements, and need not corrspond to the
> > > graph corresponding to a particular triples store. 
> > 
> > Irrelevant, see above.
> 
> ???
>  
> > > > Consider, for example, the RDF graph:
> > > > 	_:a ex:b _:c .
> > > > 	_:d ex:e _:f .
> > > > What is the CBD of _:a in this graph?
> > > 
> > >   _:a ex:b _:c .
> > > 
> > > Exactly where is the confusion? How would you expect it to be
> > > different?
> > >
> > > I see no statements that would suggest that any of the
> > > nodes in the above example graph are co-denotational
> > > with any other.
> > > 
> > > Am I missing something?
> > 
> > Yes, indeed, you certainly are.  There is, of course, nothing 
> > in the graph
> > to say that any of the nodes in the graph are 
> > co-denotational, but there is
> > also nothing in the graph to say that they are not.  Given this
> > uncertainty, why should the CBD of _:a *not* include
> >  	_:d ex:e _:f .
> 
> Whatever you're smoking, can I please have some?  

Thanks for this again insightful comment.  I do not believe that it is
worthwhile to continue this discussion.

[...]

Received on Friday, 1 October 2004 13:44:43 UTC