RE: Revised draft of CBD

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Karsten Otto
> Sent: 12 October, 2004 14:48
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: eric@w3.org; pfps@research.bell-labs.com; www-rdf-interest@w3.org
> Subject: RE: Revised draft of CBD
> 
> 
> On Tue, 12 Oct 2004 Patrick.Stickler@nokia.com wrote:
> > [... large snip ..]
> > OK. I think I finally have a grasp of what a CBUD is. It's basically
> > performing the CBD extraction "downwards", so that all object nodes
> > are either URIrefs, literals, or bnodes not acting as the subject
> > of any statement in the source graph;
> >
> I am not quite sure what you mean by "downwards", but I think 
> this part
> so far is what I intended. The CBUD contains *only* inbound arcs with 
> respect to aReallyGoodBook: either directly as to aBookCritic, or
> indirectly as to anotherBookCritic (via blank node) and 
> aReviewMagazine
> (via reification). I attached a GraphViz rendering of the CBUD just to
> be sure.
> 
> > and then doing essentially
> > the same thing "upwards", so that all subject nodes are URIrefs.
> >
> Assuming "upwards" means outbound arcs, 

No. By upwards I mean inbound arcs. I.e., upwards is from object to subject. 
Downwards is from subject to object.

Do I have us completely confused by now? ;-)

> computing the 
> CBD for all nodes in the graph so far. I think that is a bit too much
> information, e.g. in a "description" of aReallyGreatBook the relation
> to aReviewMagazine is too weak to justyfy an inclusion of its 
> respective 
> CBD. Thats what I meant by "blurring the description".
> 
> To avoid this, I think it is better to turn the process around, i.e.
> start with the normal CBD ("upward"), and then add the CBUD 
> ("downward") 
> for all nodes contained in it. This yields an extended version of your
> original SCBD, with inbound arc depth greater than 1 where necessary
> and including reifications of these.
> 
> > Fair enough. And that may arguably be a better definition, and more
> > useful form, for a SCBD. Or we could define both and differentiate
> > between them in terms of whether the upward "symmetrical" portion
> > is partial or full. E.g.
> >
> > PSCBD "Partially Symmetric CBD" (present def of SCBD)
> > FSCBD "Fully Symmetric CBD" (CBUD)
> >
> > Different applications will prefer one over the other. In the
> > case of a PSCBD, the application is mostly concerned with the
> > predicate of statements where the objects occur, so 1-level
> > deep is OK, and bnode subjects for those in-arc statements are
> > OK. In the case of a FSCBD, the application is interested in
> > directly related resources, and their descriptions, as well as
> > the resource denoted by the starting node.
> >
> > Both of these are likely to be very useful to particular kinds
> > of applications, and having them defined in a standardized manner
> > is a good thing.
> >
> Agreed, assuming the definition above for FSCBD.
> As an extended form of CBD it is probably even URIQA compatible :-)

Well, any description which is a superset of a CBD would be URIQA
compatible. It's the descriptions such as IFCBD which are subsets
of a CBD which are not URIQA compatible.

> Nevertheless I think CBUD is also useful by its own, in particular
> to answer the question "who uses this resource" in a concise manner.
> Its degree of conciseness is the same as a regular CBD,
> since CBUD is just an inverted form of it.

Sure. I expect that most if not all forms of description are
very useful for various kinds of applications. Absolutely, so
define it and publish the definition somewhere, and others
who have similar needs can then reference that definition etc.

> > That said, insofar as the CBD document is concerned, I don't
> > plan for that to become a clearing house of definitions of
> > various forms of descriptions -- as it is meant to reflect
> > what Nokia has found to be particularly useful, not to
> > speculate about what may also be useful in other application
> > areas. Even the section defining SCBDs and IFCBDs is hard
> > to fully justify on those grounds, but I will retain it as
> > it is useful to illustrate the point that CBDs are not presumed
> > to be the only useful form of description (even if, possibly,
> > the most generally useful for the broadest range of applications).
> >
> > How or where various commonly used forms of description could
> > be documented and presented as a whole is an open question.
> >
> > I would love to see either the DA WG or the SW BP WG produce
> > a non-normative advisory document along those lines, but
> > something less formal, done as a collaboration of interested
> > parties, would be good too.
> >
> 
> +1

Cheers,

Patrick

Received on Tuesday, 12 October 2004 12:01:12 UTC