Re: Making Rules Out of RDF-Graphs (Re: What is an RDF Query?)

>  >                                                              Basically I am
>>  saying that you should first axiomatize RDFS and only later consider rule
>>  systems that might be expressive enough to capture this
>>  axiomatization.
>
>Sounds like a good practice.  Anyone out there psyched to axiomatize
>RDFS?

Why *axiomatize* it? Seems like a waste of time to me, largely, since 
all you do is shift the semantic burden onto the language used to 
write the axioms. I've written a model theory for RDFS and RDF (minus 
reification and fancy-schmansy containers; available shortly).

If you really want axioms, then the Fikes/McGuinness axiomatization 
of DAML already contains an axiomatization of RDFS.  But be aware 
that there are some ongoing issues with the use of KIF in this 
axiomatization. (See the RDF-logic archive.)

>  I'd naively imagine it would be relatively easy given the DAML
>axiomatization.
>
>Meanwhile, rules (for many other applications) seem more important to
>me than RDFS....    (maybe that's an overstatement.   they are
>differently-imporant, for different applications.)
>
>>  To
>>  require that an RDFS rule extension be powerful enough to capture the
>>  axiomatization of RDFS is, to me, putting some cart before some horse that
>>  is supposed to pull it.
>
>I don't see the rules I'm talking about as "an RDFS rule extension".
>I see them as a basic tool one can use, along side RDF data, to do a
>variety of things.     One of those things might be data validation.
>One of the approaches to data validation might use RDFS.
>
>>  Aside from any other problems, if you use ``holds'', then you can't appeal
>>  to any existing version of Horn rules, at least any version that I know of,
>>  as none of them use ``holds''.  Your syntax will have to be given
>>  independant meaning, and may work very differently from anyone's intuitions
>>  of Horn rules.
>
>Maybe I'm not really understanding "holds".  The implementation I'm
>thinking of is XSB's HiLog, which rewrites all uses of the predicates
>you name as "higher-order" into a form like "apply(predicate,
>arguments)".  I was under the impression "holds" was being used in a
>similar essentially-syntactic manner, to combine HOL-syntax and
>FOL-semantics.

Yes, it is, that's right. In newer versions of KIF you can just use 
the HOL (actually strictly speaking only a subset of true HOL) syntax 
without coding it into the 'holds' form. Its still a first-order 
logic, though.

>
>When I'm actually writing code (in prolog or FOL), I use something like
>    rdf(subject, predicate, object)
>so the RDF "predicate" element has no special meaning in the language,
>which sees only the 3-ary predicate "rdf".
>
>>  > > > My big concern with it is that
>>  > > > I hear DAML+OIL cannot be expressed axiomatically in Horn logic.
>>  > > > Obviously there may be performance issues to this approach, but I
>>  > > > think that can be addressed behind the scenes, without changing the
>>  > > > general query/rule model.
>>  > >
>>  > > Certainly there are many portions of DAML+OIL that cannot be captured in
>>  > > Horn rules, including number restrictions.
>>  >
>>  > I think these ought to be clearly spelled out in some DAML docs, when
>>  > someone gets a chance.
>>  >
>>  >     -- sandro
>>
>>  Why?  DAML+OIL doesn't concern itself with rules.  Therefore it shouldn't
>>  need to say whether its can be implemented in Horn rules ...
>>
>>  peter
>
>Maybe I'm just a guy holding a hammer called "Horn" but it seems
>useful to me.  There are a variety of ways one should evaluate a
>proposed technical standard, and this seems like a useful angle,
>somewhere between a pure-theory analysis and running code.

I would suggest that it is better practice to keep the 'pure theory' 
( I presume you mean a logical semantics) separate from running code, 
at least at first. They are related, of course, in well-understood 
ways, but they aren't identical. (For one thing, the same theory 
supports a whole lot of different kinds of running code.) The issues 
that arise in trying to do both at once get very subtle and difficult 
to handle, and invite all kinds of confusions. Why jump into the deep 
water?

>      -- sandro


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 18 September 2001 11:11:38 UTC