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, this would be like 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 :-)

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.

> 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

Regards,
Karsten Otto