RE: problems with concise bounded descriptions

> -----Original Message-----
> From: ext Dan Brickley [mailto:danbri@w3.org]
> Sent: 01 October, 2004 14:35
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: eric@w3.org; pfps@research.bell-labs.com; www-rdf-interest@w3.org
> Subject: Re: problems with concise bounded descriptions
> 
> 
> * Patrick.Stickler@nokia.com <Patrick.Stickler@nokia.com> 
> [2004-10-01 14:27+0300]
> > > > We do not assert that it is perfect, either for any particular
> > > > application, or for even for a majority of applications. 
> > > 
> > > I'm happy to see the idea written up, and I think it'll find 
> > > a niche in
> > > certain applications.
> > > 
> > > Re 'perfect', http://www.w3.org/Submission/2004/SUBM-CBD-20040930/
> > > does say (in the abstact), 
> > > 
> > > 	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.
> > > 
> > > ...where 'optimal' suggests a certain comfort with the 
> design, on my
> > > reading of http://dictionary.reference.com/search?q=optimal
> > 
> > I *do* assert that CBDs are *an* optimal unit of specific knowledge.
> > 
> > I do *not* assert that CBDs are either *the* optimal unit 
> of knowledge,
> > or a *perfect* unit of knowledge.
> > 
> > There may be equally optimal units of knowledge for similar 
> applications.
> > 
> > There are surely ways that the definition of CBDs can be improved.
> 
> OK I'm not going to quibble over that one word, beyond noting that
> 'optimal' to me suggests 'the' rather than 'a'. 

Oh, I think the 'the' is lurking in there somewhere, at least
as it reflects my own point of view, but deliberately and
explicitly said 'an' so that I could (hopefully) avoid
any long drawn out debates about it ;-)

If you insert "(for the kind of stuff Nokia uses CBDs for)" after
"optimal", then perhaps that would make it easier for you to
swallow, eh?...  ;-)

> > > The point about foaf:maker/foaf:made (and 
> depicts/depiction) was just
> > > that there is an asymmetry in the design of the RDF 
> syntax, since it
> > > projects directedness of RDF arcs on to nestedness of XML 
> > > elements. This should
> > > be of no consequence to those working with the RDF model, 
> in theory.
> > > 
> > > However in practice, we find that designers of RDF vocabs feel the
> > > likely RDF/XML encoding of instance data using their 
> properties is a
> > > (perhaps minor) design constraint on their property naming 
> > > choices. CBD
> > > has a similar asymmetry, treating a graph built from 'depicts'
> > > differently from another couched in terms of 'depiction', 
> > > despite their
> > > being true description of the world under pretty much(*) the same
> > > circumstances. 
> > 
> > I consider inference to be the better way to address issues
> > of symmetry of knowledge (possibly implicit) versus asymmetry
> > of presentation/expression.
> > 
> > Thus, an asymmetrical presentation can neverhtheless reflect
> > a (subset of) fully symettrical knowledge.
> > 
> > It's been my experience that resource-as-subject-only (asymmetrical)
> > knowledge is far easier to work with when directing particular
> > tasks/processes than having to work with 
> resource-as-subject-or-object
> > (symmetrical knowledge).
> > 
> > Of course, that's just my own experience, and I don't at all mean
> > to suggest that it constitutes the usual experience.
> >  
> > > My concern then, was just that CBD would introduce yet
> > > another factor into RDFS vocab design, actually a very 
> similar bias to
> > > that already associated with the RDF/XML syntax: vocab 
> designers would
> > > have to think more carefully about the direction in which 
> they name
> > > their RDF properties, even though the pure RDF graph view of this
> > > suggests they shouldn't have to.
> > 
> > Actually, if the designers simply capture the symmetric relations
> > between properties, then using inference, one can decide freely
> > whether a symmetric or asymmetric perspective is most useful.
> 
> OK, I can see that working for tools that deal with inverses. Running
> CBD over system that understands inverses could be differently optimal
> to using it over a raw RDF graph store...

In my experience, CBDs are far more useful when the source agent
is able to reason about what it knows about the resource in question
rather than just do "stupid" pattern based extraction of triples 
from a triples store. 

Patrick

Received on Friday, 1 October 2004 12:05:27 UTC