RE: Revised draft of CBD

OK, I finally got some time to read through your paper and
look at the Dbin stuff in more detail.

All in all, *very* cool, and I can think of a number of ways
we could put it to use in a mobile environment (as well as
elsewhere in the usual intranet/internet context).

Comments below...

> -----Original Message-----
> From: ext Giovanni Tummarello [mailto:giovanni@wup.it]
> Sent: 05 October, 2004 17:05
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: mbatsis@geekologue.com; www-rdf-interest@w3.org
> Subject: Re: Revised draft of CBD
> 
> 
> Hi Patrick :-) I really think the concept of MSG (minimal 
> self containe 
> graph [1]) should pop in place ..

If I understand it correctly, an MSG appears to be a CBD
without reifications.

A MSG would also seem then to be the same as a Joseki 
"bnode closure".

I originally started out with URIQA descriptions equating
to an MSG/bnode closure, but quickly realized that it was
incomplete, and thus not sufficiently general.

While not everyone is fond of reifications, and not everyone
uses them, they are, nevertheless, part of the RDF standard
and there are valid uses for them.

And as it turns out, we use them ourselves to qualify assertions
for relevance in various ways, which can affect (among other
things) search result ranking and thus target section for particular
actions/decisions.

> a Symmetric CBD (which i'll call it RDFN [1] since this 
> definition came 
> earlier ;-) )

Fair enough ;-)

> is really made of  the union of all the MSG .

OK. It seems that an RDFN is an SCBD without reifications. 

> BASICALLY you can think there is one MSG per outgoing 
> triple.. but not 
> quite.. in case of 2 triples having the same blank node as a 
> target this 
> is not true (but this case is covered ) . The reason why MSG 
> are worth 
> mentioning is that they are the minimal unit of contributed 
> information 
> and can have a digital signature on themself in a elegant 
> way, that is, 
> just a single reified triple.  I know the "quadruple" people probably 
> dont have need for this but since in DBin [2] we're sticking 
> to the good 
> old triple model we kind of like this.

Sounds OK to me, though I'd advise including reifications in both
MSGs and RDFNs -- i.e. to use CBDs and SCBDs. 

Omitting the reifications constitute a loss of what may be crucial
knowledge for properly interpreting statements in the "MSG subset"
of a CBD (or "RDFN subset" of a SCBD). Thus, a MSG or RDFN do not
include "the whole story" about a resource denoted by a given URI.
 
> being that the term "minimal" is pretty justified (in msg) and that a 
> SCBD/RDFN is a list of them  maybe a  possile name could be List of 
> Minimal Annotation(s)? LMA ? dont know. Just ideas here. of course :-)
> 
> I am fairly entusiastic about this sort of things :-) the 
> computational 
> tractability of RDFNs are what make them.. a great tool for 
> semantic web 
> spread really.. as they allow "open" p2p scenarios (as we 
> argue in the 
> paper, those whee you dont want otheres to be ideally capable 
> of hogging 
> your server with a single query). ..

>From the usage side of things, I can see how RDFNs and SCBDs
are valuable constructs. Though from the side of "basic" knowledge
discovery and interchange between arbitrary agents, I think there 
are significant potential scalability issues when asking for RDFNs
or SCBDs, particularly for generally used classificatory terms, which
would make MSNs/CBDs more appropriate as a "default" form of
description.

I'd be very interested in hearing about your practical experience
in interchanging RDFNs with regards to magnitudes of RDFNs in
practice.

Of couse, what may be a scalability problem for a mobile/embedded
agent (both per local capacity limitations and mobile bandwidth
limitations) may be a non-issue for desktop servers with broadband
connections. This is another issue that must be kept in focus if
we are to have a semantic web that allows our information to 
follow us around as we go from home to car to work to travel, etc.

> So shall we open a project collecting all the open source( 
> NON GPL, will 
> the nokia stuff on sourceforge be non gpl? ) 

It is released under the Nokia Open Source License, which is
not quite as open as GPL, but close.

> implementations 
> and tools ? 
> i'll start contributing with the fore mentioned signign APIs
> Maybe it might be a good idea to make a formal paper about these 
> definitions/properties/apis ? :-) private communication will follow.

==

A significant, but complementary, distinction that I see between URIQA
and Dbin is the difference in focus between facilitating a intersection
of ontological commitment between automated agents operating on behalf
of human users (URIQA) versus facilitating an intersection of
ontological usage between users employing automated agents (Dbin).

There are two different sorts of questions that can be asked given
a particular URI:

1. What does this URI mean? I.e. what are the inherent characteristics 
   of the resource denoted by this URI.

2. How is this URI used? I.e. what are the relationships of the resource
   denoted by this URI with other resources.

Granted, there will usually be an intersection in the answers to both
of these questions, but the questions, and their use cases, are 
nonetheless distinct, as are the form of the answers.

The answer to the first question should be, IMO a CBD.
The answer to the second question could very well be an SCBD.

I think these two use cases are complementary. In fact, one can
see the first use case as a specialization, or inherent component, 
of the second, which is reflected by the fact that a CBD is a subset 
of a SCBD.

Many (most?) agents (especially mobile/embedded agents) will be very 
selective about the information desired/needed per a given URI, and 
will be concerned primarily about shared ontological commitment with 
the other agents it communicates with, and ask for CBDs. 

Other agents, such as agents working on behalf of applications such 
as Dbin, will be looking at the broader scope of usage, and thus will 
ask somewhat broader questions about the URIs they encounter, e.g.
RDFNs/SCBDs.

Having CBDs as a default, but having both CBDs and RDFNs/SCBDs 
defined in a standardized way so that broad support for both can
be encouraged and either can be easily requested, would be IMO
a very good thing.

Question: have you explored the significance of RDFNs over MSGs
in actual utility of the syndicated knowledge? I.e. have you tried
only exchanging/syndicating MSGs rather than the broader RDFNs?
If so, does that limit the utility of query results? What operations,
decisions, etc. do the "missing" arc-in statements offer in the
Dbin environment?

Cheers,

Patrick


> [1]  Toward widely deployable Semantic Web P2P: tools, 
> definitions and 
> the RDFGrowth algorithm.
>        
> http://www.dbin.org/twiki/pub/About/WebHome/RDFGROWth_workshop
ISWC2004.pdf
[2]  www.dbin.org


Patrick.Stickler@nokia.com wrote:

>I have revised [1] the CBD document [2] to (attempt to) address comments
>
>recieved both in conjunction with the W3C submission process as well as 
>in recent discussions on rdf-interest.
>
>Please give special attention to the note on terminology [3] provided at
>
>the end of this revised draft.
>
>Note that this revision reinstates the original definition of "concise
>bounded description", as used and deployed by URIQA and the Nokia
>Semantic Web server, and identifies a distict form of description
>"inverse functional concise bounded description" as one way to address
>the particular needs of certain applications. Please also note the
>implications of choosing one form of description over another on 
>minimal query interface requirements.
>
>Constructive, friendly comments on this revised document offered in
>goodwill 
>for the benefit of all concerned, and taking fully into account the
>context
>and manner in which the document is presented [3], are most welcome.
>
>Regards,
>
>Patrick
>
>
>[1] http://swdev.nokia.com/uriqa/CBD.html
>[2] http://www.w3.org/Submission/CBD/
>[3] http://swdev.nokia.com/uriqa/CBD.html#r1
>
>
>  
>

Received on Sunday, 10 October 2004 10:42:30 UTC