Re: Expressing operators and functions in RDF

Drew,

Thank you very much for taking the time to respond to me. Let's see if I
understand well what you mean (note that I am not a AI expert).

>The key difference between CWM and other approaches (Sintek & Decker's
>TRIPLE system, our DRS, Horrocks and Patel-Schneider's OWL Rules) is
>that CWM allows sets of triples to be labeled as internal to a rule.
>Those triples are then not asserted.  You can't do that in RDF,
>although perhaps it will become possible in RDF++, if there ever is
>such a thing.
>

"Those triple then are not asserted. You can't do that in RDF".

If I understand well, RDF assumes that every triple is a fact (an
assertion) so they are always true.
Example: I assert 1 + 2 = 5,  which becomes in triple (CWM) style:
(1,2) math:sum 5. 

There is no way in RDF to say that this triple is non-asserted except by
using reification (but there is not standard for this). I assume what
you mean by RDF++ is the support of non-asserted statement in RDF model.
Is that correct ?

My goal is to use the simple RDF triple model to express query/rule, so
I am not introducing another model/language to express query/rule
(except adding the concept of variable). In the CONTEXT OF A QUERY OR A
RULE, I assume that every triple is NON-ASSERTED.  Basically, I can
summarize by saying antecedants of rule and queries are knowledge bases
of non-asserted statements. The query/inference engine needs to assert
the truth of every single statement in the query.

Of course this query triple cannot be mixed with a knowledge base,
because they will be no way to know what statement are true or false,
but I cannot see a case where a query would be mixed with facts. If you
see one, please give me examples.

If I have in a query a triple: (1,2) math:sum 5 in my query then the
query engine needs to check the truth of the statement if the math:sum
property is a build-in property. The query engine will state that it is
false.

About variables now:

In order to work, it is important to introduce the concept of variable
as a fundamental concept in the query/rule language (by extending OWL
such as in OWL Rule Language). To indicate that triple must match/ may
match or must not match, we should have tree flavors of variable:
mustBindVariable, mayBindVariable, mustNotBindVariable (similar to DQL
idea). 
Also every triple containing variables is AUTOMATICALLY NON-ASSERTED and
requires unification in the query engine.

>Hence the option of making a relation a property is simply not
>available to any system but CWM.  If you tried saying "if triple1 then
>triple2," the mere occurrence of triple1 and triple2 would cause them
>to be asserted, so that "if p then q" would have the same meaning as
>"p and q."

Based on my model, this cannot happen, because every triple is assumed
non-asserted. Did I miss something ?? 

>> Which one requires less parsing work ? 
>I don't understand; parsing from what to what?  What kind of work --
>programmer work or computer work?

For both. Promoting relations/operators as subject of discussion
represents the dual view of my property centric model (CWM model). If
you have already a unification engine for RDF based on Triple Match such
as Jena, the subject centric model requires to convert them to triple
pattern internally (requiring a extra-step in the processing of the
query) and requires to understand the meaning of the operand (which on
is the domain and which one is the range). I think the Subject-centric
approach is more complex to implement. 


I would like to summarize my approach and its benefits:

- Queries/antecedants of Horn rules are represented as a RDF document (
so no need for specific parser )
- In this CONTEXT, the statements MUST BE CONSIDERED AS NON-ASSERTED (I
think this is a very reasonable assumption).
- The model is mathematically correct (relation/operators are RDF
properties: they have a domain and a range).
- Simply extend current unification engine by adding built-ins
properties (such as CWM).
- Easy to publish supported operators of inference engine by publishing
the ontology of operators.
- Requires minimal change in RDF model (just adding variable concept).
- Mappable to any query language
- Easy to perform reasoning and refactor the query
- Each triple is independent and can be executed in the most adequate
order (triple with mustBindVariable first for example). 

I hope I manage to communicate my thoughts. It is possible that I am
missing something very fundamental in my reasoning, because I do not
have a strong AI background. If this approach does not work, I really
would like to know why. Thank for your patience.   


Best regards
 
Stephane Fellah
Senior Software Engineer
 
PCI Geomatics
490, Boulevard St Joseph
Hull, Quebec
Canada J8Y 3Y7
Tel: 1 819 770 0022 Ext. 223
Fax 1 819 770 0098
Visit our web site:  www.pcigeomatics.com

Received on Wednesday, 5 November 2003 12:23:20 UTC