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

RE: contribution and CBD api?

From: <Patrick.Stickler@nokia.com>
Date: Mon, 4 Oct 2004 10:39:27 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADD05@trebe051.ntc.nokia.com>
To: <giovanni@wup.it>
Cc: <www-rdf-interest@w3.org>



> -----Original Message-----
> From: ext Giovanni Tummarello [mailto:giovanni@wup.it]
> Sent: 04 October, 2004 02:18
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: contribution and CBD api?
> 
> 
> Hi Patrick,
> 
> i see you mean to write an extended version of the CBD  
> (which for some 
> reason i called CBR in my last posting :-) )..
> as I was mentioning we have worked on something similar but concept 
> since we needed it for our P2P algorithm called RDFGrowth.
> We have some stuff to contribute then.. some (Semi) formal 
> stuff  (see 
> the paper). 

Will do.

> Some API for cutting MSGs out of a graph, 
> cheching to which 
> msg a triple belongs, counting and listing MSGs around a URI 
> (they form 
> a RDFN in our RDFGrowth parlour). Checking which digital 
> signatures are 
> attached to a MSG and or attaching new ones. etc.. But our 
> api is a bit 
> fragmented inside the current DBin project..

The CBD spec was similarly buried in some of our other
materials, but had more general utility, which is why I
split it out separately (apparently failing in numerous
ways).

Having it separate from application and query interface
issues has also helped me see how it can be presented in
a more generic manner -- which I failed entirely to do in
the current document, but will try to improve upon.

I also think having such forms of descriptions defined
in 

> Is there any open CBD api by the way? I could only find the 
> modules you 
> provide but those plug in into non free stuff..

There is a free-use license of RDF Gateway that has unlimited
functionality to the commercial-use version. C.f.

http://www.intellidimension.com/pages/site/products/pricing.rsp

Also, we are in the final stages of setting up a SourceForge
site for the Nokia Semantic Web Server, which serves as our
reference implementation of URIQA (and CBD). Hopefully that will
be up and working in a week or so.

> there are also other features and things that would like to 
> add and that 
> could make sense .. for example we would like to avoid that 
> certain data 
> ends into a MSG, e.g. data for "internal use" is this 
> possible retaining 
> the properties of the MSG? to be seen (i would say no but 
> there might be 
> some cases where this is ok). 

The way I'm looking at it, this is an implementational detail
that affects which graph you extract the CBD from. I.e., you
might have a triple store that contains sensitive, controlled
information -- so your public interface filters out such
information, resulting in a different, publically accessible, graph
that differs from the graph embodied in the complete triple store;
and it is from that publically acessible graph that you extract
the CBD.

Similarly for inferrable triples. You may have a triple store and
a set of inference rules, and from both, you can derive a new
graph which contains all the triples in the triples store, and all
triples inferrable by the inference rules -- and from that graph
you extract the CBD. This is what we usually do in most of our
applications at Nokia.

Now, while it's useful to present these two variants in terms
of extracting the CBD from distinct graphs, as if the graphs are
produced before the extration of the CBD begins -- in fact, the
CBD extraction and the derivation of the graph may occur in 
parallel. E.g. in our implementation, we use inference rules to
extract/identify the CBD, and those inference rules may be
used in conjunction with RDFS and OWL closure rules, and other
proprietary rules, at the same time that the CBD is being extracted.

> Also.. sesame has the tendecy to add  
> statements to fill the forward inference of RDFS things..  filtering 
> this from a MSG/CBD might be practically useful since the extra 
> statemetns can be anyway reconstructed..

I intend to address the issue of symmetric vs. asymmetric descriptions
in my revisions to the CBD document -- and I will offer rdf-interest
an opportunity to comment on a draft of those changes before the
document is re-submitted.

> .thinks that might be interesting to talk about .. anyway :-) 
> this is an 
> open invitation to maybe create a SF project with a reference 
> java API 
> and specifications..

There are already numerous APIs and other implementations for
CBDs, though I think mostly of the original definition -- which
I intend to isolate more explicitly in the revised document,
in a distinct form from the version which takes inverse functional
properties into account.

Ultimately, it would be great to see widespread support in RDF
APIs for extraction of CBDs (and other widely recognized useful
forms of descriptions) from graphs.

> About a newer name (if that can create less controversy) 

Before saying what I am about to say below, let me stress that
(a) I have great respect for mathematicians, in general, and
wish that I had had the opportunity and forsight to have aquired
more advanced skills in that area, and (b) I appreciate the 
great value of having mathematically precise definitions and
my failure to provide mathematically precise definitions is 
simply due to the fact that I do not have the sufficient skills
to express my ideas in such a manner -- nor more so than I 
have the skills to express my ideas in French or Swahili.

Now, that is, IMO, unfortunate for those who only speak French 
or Swahili, because I believe my ideas have some value. It
is equally unfortunate for those to appear to only speak
Mathematics. If those latter individuals also happen to speak
English, then all the better for them, as they may then be
able to coax some kernel of meaning out of the English that
I have written. If they do not care to bother expending that
effort, fair enough, but I would then expect them to refrain
from "bitch slapping" me for not having presented my ideas
in a mathematically precise manner, or presuming that the content
of my presentation is devoid of any merit or value because
it is not presented in a form of their liking. If they are
unsure as to my meaning, and sincerely wish a clarification,
then a polite inquiry would result in an equally polite
response.

To those mathematicians who expect everyone to use terms
which have special mathematical meaning always and ever 
in their mathematical sense, I simply offer these final
thoughts:

   Those with greater expectations will experience greater 
   disappointment.

   Don't throw the baby out with the bath water.




That said...

I consider the name "Concise Bounded Description" to be fully 
acceptable, accurate, and informative.

The only "controversy" is that which comes from mathematicians
presuming that because they might have a highly precise, narrow, 
specialized meaning for a term, that others no longer have the
right to use that term per its other, more widely used, long
established meanings, in contexts which are non-mathematical.

(and, quite honestly, any mathematician who reviews the CBD document
 should easily and quickly conclude that it is not a mathematical
 presentation, and criticisms against the presentation based on
 supposed "misuse" of certain terms because they do not conform to
 some specialized mathematical usage are both unreasonable and to a
 certain degree, rude)

Per http://www.webster.com/ :

Main Entry: con·cise
Pronunciation: k&n-'sIs
Function: adjective
Etymology: Latin concisus, from past participle of concidere to cut up, from com- + caedere to cut, strike
1 : marked by brevity of expression or statement : free from all elaboration and superfluous detail
2 : cut short : BRIEF
- con·cise·ly adverb
- con·cise·ness noun

Main Entry: bound
Function: transitive verb
1 : to set limits or bounds to : CONFINE
2 : to form the boundary of : ENCLOSE
3 : to name the boundaries of

Main Entry: de·scrip·tion
Pronunciation: di-'skrip-sh&n
Function: noun
Etymology: Middle English descripcioun, from Middle French & Latin; Middle French description, from Latin description-, descriptio, from describere
1 a : an act of describing; specifically : discourse intended to give a mental image of something experienced b : a descriptive statement or account
2 : kind or character especially as determined by salient features <opposed to any tax of so radical a description>
synonym see TYPE

and regarding the choice of one particular heading in
the document in question:

Main Entry: def·i·ni·tion
Pronunciation: "de-f&-'ni-sh&n
Function: noun
Etymology: Middle English diffinicioun, from Middle French definition, from Latin definition-, definitio, from definire
1 : an act of determining; specifically : the formal proclamation of a Roman Catholic dogma
2 a : a statement expressing the essential nature of something b : a statement of the meaning of a word or word group or a sign or symbol <dictionary definitions> c : a product of defining
3 : the action or process of defining
4 a : the action or the power of describing, explaining, or making definite and clear <the definition of a telescope> <her comic genius is beyond definition> b (1) : clarity of visual presentation : distinctness of outline or detail <improve the definition of an image> (2) : clarity especially of musical sound in reproduction c : sharp demarcation of outlines or limits <a jacket with distinct waist definition>
- def·i·ni·tion·al /-'ni-sh&-n&l/ adjective

(love that first sense ;-)

Now, if the mathematicians consider that simply so much 
incoherent blathering, well, cest la vie. Just pass it by.


> maybe it might 
> be a good idea tocalling this thing, "minimal" .. with respect to the 
> property that you can transfer a whole rdf graph bit by bit . 
> That might 
> get away with the bounded. so it could be called MD ?
> 
> by the way, are you aware of others using this kind of tool ?

I understand that Gnowsis employs CBDs, and have seen other
references to CBD or CBD-like functions/methods in other
applications.

I have not maintained any explicit list, though.

Regards,

Patrick
Received on Monday, 4 October 2004 07:40:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:09 GMT