RE: problems with concise bounded descriptions

> -----Original Message-----
> From: ext Peter F. Patel-Schneider 
> [mailto:pfps@research.bell-labs.com]
> Sent: 01 October, 2004 16:51
> 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 16:21:32 +0300
> 
> 
> > > > > 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.  

OK. Well, I can appreciate that "formally represented" would
be sufficient for you, but I was trying to write to a much
broader audience, many of which I think will understand what
I mean by "explicit" and appreciate my use of that term.

We all know the problems of natural language, and if/when
something akin to CBDs might ever be defined in a more
official specification (rather than a document intended to
be a friendly exchange of ideas from one member others) then
I expect that much more work will have to go into getting
the wording just right.

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

OK, OK, I see what you mean. 

I still don't see that this has any real bearing on the
CBD spec itself, but more concerns the context of application
of CBDs, such as with particular query interfaces, etc.

True, if the responding agent which is providing
the CBD also responds to other forms of queries which can
provide other forms of responses which have intersecting
statements, then, yes, it is true, one could theoretically 
obtain "explicit/formal knowledge" "separately from the
same source".

Though I certainly wouldn't see that as a "problem" with 
CBDs, specifically; merely a (minor) ambiguity in the
document.

And while it would certainly be better for the document
to be much clearer on that point, it is, I think, rather 
splitting hairs.

The fact that CBDs are not a reasonable representation of
results to a query such as "return all the triples with
ex:b as the object" does not IMO in any way lessen the
utility of CBDs. It's apples and oranges.

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

Oh come now, do you really expect me to respond to
such things? Believe me, I've got far more important
things to do...

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

Sorry, but I don't intend to be drawn into that discussion.

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

Where? How? Co-denotation is irrelevant to the process of
extracting a CBD from a given body of knowledge. 

One begins with an RDF graph. How one *got* that RDF graph,
and whether that RDF graph is stored persistently and entirely
in a triple store, or whether is a combination of
persistently stored triples and dynamically inferred triples,
is entirely out of scope.

You have a graph. You have a node in that graph. You extract
the CBD. At what point in that process is co-denotation an
issue to the extraction of the CBD per that particular graph
starting at that particular node?

Answer: it's not.

If you think it is, and can show me it is, go for it.

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

It's not clear to me exactly what you find wrong with
that text, or why the latter wording would be in any
way better than the first, much less, make better sense.

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

You're welcome. I do my best ;-)

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

Apologies.

Just trying to keep some thread of humor in this. Really.

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

Sorry, but I found your question to be incoherent, given 
the stated goal of CBDs, namely the interchange of knowledge
to be used by automated agents.

Perhaps it was a rhetorical question -- intended to highlight
something that is not explicitly stated but should be???

Namely, that if some agent does not posess some bit of
knowledge, then it should not guess or fabricate such
knowledge, just in case it might be true. 

I.e. if the agent has no idea whatsoever about whether
two nodes do or do not denote the same resource, it shouldn't
guess that they do, just in case they do, and merge the
descriptions expressed in terms of those two nodes.

Well, er, duh.

And, I consider such behavior to be so obvious, and so
fundamentally proper, that I saw no need to state it
explicitly -- and wondered that, if you saw things in
such a radically different manner, such that it might
or would be acceptable for an agent to make such presumptions
about co-denotation and behave in such a manner, that
such a remarkable, drastic difference in world view
might very well be substance induced (humor was intended).

Apologies for any offense.

Regards,

Patrick

Received on Friday, 1 October 2004 15:00:19 UTC