W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2004

RE: problems with concise bounded descriptions

From: <Patrick.Stickler@nokia.com>
Date: Fri, 1 Oct 2004 14:27:16 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50A1D9D@trebe051.ntc.nokia.com>
To: <danbri@w3.org>
Cc: <eric@w3.org>, <pfps@research.bell-labs.com>, <www-rdf-interest@w3.org>

> -----Original Message-----
> From: ext Dan Brickley [mailto:danbri@w3.org]
> Sent: 01 October, 2004 13:10
> 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 12:55+0300]
> > As for utility/cost/etc., the CBD submission is simply Nokia sharing
> > with others what we have found to work well, be very useful, and
> > likely to benefit others as well.
> > 
> > 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.

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



> Dan
> (*) I'm handwaving a little here to avoid looking silly in front 
> of model theorists
Received on Friday, 1 October 2004 11:28:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:53 UTC