RE: Concise Bounded Descriptions - updated, expanded, stand-alone definition

On Fri, 20 Aug 2004 Patrick.Stickler@nokia.com wrote:

> > > A draft of an updated, expanded, stand-alone definition for Concise
> > > Bounded Descriptions is now available
> > >
> > >   http://swdev.nokia.com/uriqa/CBD.html
> > >
> > [snip]
> >
> > Great to have this on its own page as a point of reference!
> > However, I have a problem with the new concept of the inverse
> > functional
> > bounded description: It requires that both the sending and receiving
> > agents are schema/ontology-aware, and also that they share the same
> > schema/onology-knowledge, in order to correctly create and interpret a
> > CBD.
> >
> > For once, the sender needs to know that a given predicate is an
> > owl:InverseFunctionalProperty, so it can pick the "if"-branch of the
> > IFBD definition for an anonymous resource. However, this knowledge
> > may not always be available, e.g. in case of a simple semantic web
> > crawler. AFAIK the issue of finding all schemata/ontologies
> > for a given
> > RDF graph is not solved in general yet - or is it?
>
> If the sending agent is not aware that a given property is
> an owl:InverseFunctionalProperty, then it proceeds as if it
> is not.
>
Ok, seems like I interpreted too much into the definition. I took it as
a MUST, and without getting to philosophical, an IFP *is* an IFP wheteher
I know it or not. But from your reply I gather it should read something like
"where the predicate *is known to be* an owl:InverseFunctionalProperty".

> Then again, if the agent has no knowledge about the property,
> it (ideally) would be able to submit a URIQA request to the
> metadata authority and obtain the information it needs.
>
Yes, this makes sense for a more complex agent. But I was thinking of a
simpler case, such as a passive RDF database with a frontend for answering
queries with CBDs (e.g. via URIQA :-)

Also, what is the "metadata authority" you mention?

> However, the definition/generation of CBDs still works just
> fine if such information is not available -- in fact, it is
> then the same as the original definition of CBDs.
>
> > Furthermore, the receiver also needs to know that a given predicate
> > is an IFP. This is a more serious issue, as it needs this to determine
> > whether the "if"- or the "else"-branch of the IFBD definition
> > was picked
> > by the sender. In the "else" case, it already has all known
> > statements,
> > but in the "if" case it might need to issue another query (by IFP).
> >
> > Consequently, if the IFP is unknown to the receiver, it might falsely
> > conclude that it already got all information the sender had on the
> > resource.
>
> Well, I think it is fair to presume that if the recieving agent
> is going to do anything particularly useful with (i.e. make decisions
> based on) the recieved knowledge, that it will have to be aware
> of the vocabularies/ontologies in which that knowledge is expressed.
>
Agreed. However, the open nature of RDF implies that an agent does not
need to understand every statement in a graph. If a receiver does not
understand the IFP the sender used to "prune" the CDB, it will mistake
the pruned graph for the whole thing. IMHO there should be a way to
distinguish the two cases.

> Also, and again, I personally do not see CBDs as a complete
> solution to knowledge interchange between semantic web agents.
> Something equivalent or comparable to URIQA must also exist so
> that agents can further obtain the knowledge they need.
>
Of course. But my point is that the receiver cannot know that it
needs to send another query in the problematic case. In fact, as it
does not know the relevant IFP, it does not even have the necessary
parametes for the query.

> > I see two possible solutions to this problem: The CBD could contain
> > the relevant "ppp rdf:type owl:InverseFunctionalProperty" statements,
> > or indicate all relevant ontologies by way of owl:includes.
> > However, neither solution is viable for RDF-only cases, such as
> > querying the aforementioned simple spider agent.
>
> Or, if the recieving agent has no knowledge about those properties,
> it can either submit a URIQA MGET request, or ask the same source
> of that knowledge for additional knowledge about those properties.
> I.e., ask the sending agent what it knows about those properties
> (by sending the CBD of each, etc.)
>
> I see the definition of CBDs as a componenent of a general
> bootstrapping mechanism for the semantic web, not as an all
> encompassing solution to knowledge interchange.
>
Yes, and I dont expect them to be anything else. But I was thinking of
a scenario where the receiving agent has limited resources (memory,
bandwidth, CPU power), for example because it resides on a tiny embedded
device. For that reason it cannot cache all ontologies it might encounter,
or ask for the precise definition of everything it finds. But it can
answer simple queries on the triple level, like "find me things of
rdf:type dev:Printer with foo:location bar:Room5". The lookup service
has some _:p in its database that matches these criteria, but also has
the IFP comp:uniqueDeviceNumber. The agent does not know the comp
ontology, so it does not know the information about _:p is pruned, and
would match if another query were formed. (Sorry for this hasty example)

> > By the way this seems to be a more general case of the "crossing layer
> > boundaries"-problem previously discussed (but not solved) in another
> > mailing list thread [1].
>
> Well, given the examples you present in that referenced document,
> I would say that those "missing triples" are provided for by the
> closure rules defined in the RDF model theory. Triples that can be
> inferred are not the same as triples which are simply not included
> in a graph, but must be obtained separately.
>
Well, I think the cases are similar in that there the receiver is supposed
to understand rdfs:subClassOf etc, where here it is supposed to understand
owl:InverseFunctionalProperty. If the receiver does not understand these,
it will fail to process the information in the way the sender intended.

> The whole point of CBDs is that they are *not* exhaustive -- but only
> provide that information which cannot be obtained by separate queries
> to the same source. The total body of knowledge which a given agent
> requires to do some task will likely require the syndication of many
> CBDs about many resources. CBDs are simply a useful, optimal unit
> of interchange.
>
> Cheers,
>
> Patrick
>
>
> > Regards,
> > Karsten Otto
> >
> > [1]
> http://lists.w3.org/Archives/Public/www-rdf-interest/2003Sep/0082.html
>
>

Received on Friday, 20 August 2004 13:56:45 UTC