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 Peter F.
> Patel-Schneider
> Sent: 01 October, 2004 02:40
> To: www-rdf-interest@w3.org
> Subject: problems with concise bounded descriptions
> 
> 
> 
> In the DAWG message archive I came across a reference to a W3C member
> submission from Nokia on Concise Bounded Descriptions
> http://www.w3.org/Submission/CBD/.

That was quick ;-)
 
> 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.

> 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.

> Problem 3:  What is ``obtain separately''?

By separate request/query.

> 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 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?  

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).

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. 

> 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?

> Problem 6:  This definition does not satisfy the initial 
> description of a
> CBD.  Consider, for example, the RDF graph:
> 	ex:a ex:b ex:c .
> 	ex:r rdf:type rdf:Statement .
> 	ex:r rdf:subject ex:a .
> 	ex:r rdf:predicate ex:b .
> 	ex:r rdf:object ex:c .
> the CBD of ex:a in this graph is the graph itself, but it 
> includes explicit
> information about ex:r, a potentially different resource.

OK. I can see a minor issue with some of the wording in that
it states that no other named resources will be described in
the CBD (presuming that reification resources are anonymous,
rather than named) but as the core of the algorithm is quite
clear about reification resources, this is a minor editorial
issue (that I will address).

> Problem 7:  This definition does not provide enough information to
> distinguish the node from other distinguishable nodes in the graph.
> Consider, for example, the RDF graph: 
> 	ex:r rdf:type owl:InverseFunctionalProperty .
> 	_:a ex:r _:b .
> 	_:b ex:r _:a .
> 	_:a ex:s "NODE A" .
> 	_:b ex:s "NODE B" .
> Then the CBD of _:a in this graph is
> 	_:x1 ex:r _:x2 .
> 	_:x2 ex:r _:x1 .
> which is the same as the CBD of _:b in this graph but _:a and _:b are
> distinguishable in the graph and thus should have different CBDs.

Well, firstly, while it is possible to obtain a CBD of 
an anonymous node, the focus of a CBD is a resource
denoted by a URIref (not that I see that it's significant
to this, or any of these, examples).

I.e. the beginning point for the extraction of the
CBD by the responding agent, posessing the knowledge
in question, is a graph node, but the request from
one agent to another can only be made in terms of
a URIref.

This probably could be made clearer in the CBD spec.

Secondly, The CBD of _:a, in the context of the agent
recieving/responding to the request would be

  	_:a ex:r _:b .
  	_:b ex:r _:a .
 	_:a ex:s "NODE A" .
 	_:b ex:s "NODE B" .

which, yes, entails

  	_:x1 ex:r _:x2 .
  	_:x2 ex:r _:x1 .
 	_:x1 ex:s "NODE A" .
 	_:x2 ex:s "NODE B" .

neither of which are not going to be particularly useful
to any requesting agent since (a) it couldn't
ask for the CBD of a resource denoted (solely)
by an anonymous node in some other agent's
knowledge base (since anonymous node labels are
system, and hence agent, local) and (b) even
if the agent was somehow able to make the request
(which it couldn't) it wouldn't know which anonymous
node(s) in the response actually denote the resource
of interest.

Patrick

Received on Friday, 1 October 2004 11:20:03 UTC