W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2007

[RIFRAF] Re: Approaching an XML syntax for RIF

From: Axel Polleres <axel.polleres@urjc.es>
Date: Thu, 08 Feb 2007 01:47:51 +0100
Message-ID: <45CA7337.1010001@urjc.es>
To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
CC: Sandro Hawke <sandro@w3.org>

more comments here, on the Ontologization issue for RIFRAF

Sandro Hawke wrote:
>     - skip a property stripe when there can only be one property for
>       this class.  (A broader rule would involve selecting a "primary"
>       property, or even a sequence of properties, but so far I'm trying
>       to keep asn06 a subset of OWL, and I don't think OWL has anything
>       like that.)  

about this particular one: indeed "there can only be one property for 
this class" is not expressible in OWL.
  not sure whether it matters thought to link asn and ontology in the 
end, but might make it hard to "sell" asn06 as an easier to read OWL 
syntax, as we discussed on 30th in the telconf.

>     - Never skip a property when its range is the same as one of the
>       classes consecutively skipped above it.  (That would introduce an
>       ambiguity.)

> The results are pretty encouraging, but still preliminary.  I was hoping
> to have demo code releasable by last Friday, but it's still not really
> working right, and we're at the point where I obviously need to send
> this e-mail to allow for discussion on Tuesday.   My sincere apologies
> for the delay.
> Here's an asn06 specification of the Condition language, with input
> from Harold, but he hasn't see this version.
> ================================================================
>     default namespace rif = "http://www.w3.org/2007/01/rif#"
>     class Condition
>         subclass And
>             property formulas : list of Condition
>         subclass Exists
>             property declare : list of Var
>             property formula : Condition
>         subclass Atom
>         subclass Equals
>             property equated : list of Term
>     class Composite
>         property parts : list of Term
>         subclass Atom
>         subclass Term

Atom is a subclass of Condition and a subclass of Composite?
Term is a subclass of Atom, or what? I am a bit confused here, but...

>     class Term
>         subclass Expr

  ... this had been clarified in Dave's mail later on, I guess?

>         subclass Var
>             property name : xsd:string
>         subclass Con
>             property ref : xsd:anyURI
> ================================================================    
> Some issues with this:
>     - it calls out the similarity between Atoms and Terms (note the
>       multiple inheritance.)  I'm not sure that's a good idea. 
>       In a sense Atoms and Terms are very different things.

yes in first-order, no in HiLog or higher-order logics.
This is why I modeled this differently in my ontologization attempt [1] 
and didn't make a real distinction so far, Prolog eg. makes no such 
differnce. I.e. in the ontology, which shall be extensible, we shouldn't 
make this distinction, but try to axiomatize what is allowed in RIF Core.

  You can then simply define subclases of constant, predicate and 
function symbol, where
* a constant that appears as a nested functor is a function symbol and
* top-level constants in terms are predicate symbols.

Then, you further would need to axiomatize for RIF that predicates and 
functions are not allowed to be mixed, you'd need to do this on the 
ruleset level and state that the two classes are disjoint for RIF Core 
or so, agreed?

>     - it puts the predicate/function as the first element in a list,
>       rather than as a separate property. This is a coin-toss
>       decision, to me. Sometimes you want to just have it be another
>       member of a list, sometimes you want to treat it specially.  It's
>       easy enough to convert.   This makes the XML look simpler.

I did, in the ontologization proposed something different.
I introduced a general concept of parameter, which has three properties
  hasFunctor for tha parameter name,
  hasParamPos, for the parameter position, and
  hasParamValue, for the actual parameter value

This caters for both slotted and ordered parameters in terms.
For guaranteeing order, you'd need to axiomatize that
* it is not allowed that a term has positional and named parameters 
mixed, i.e. either there's a functor name or a positional parameter,
* if there are positional parameters defined, thay must be unique and 
there might not be parameters missing.

What I mean to say is: What you propose for modelling first-order terms 
with lists is probably enough for the core, but might need refinement, 
where what worries me is extensability in other dialects.

>     - it uses short names like "Con" instead of "Constant"

>     - it uses lists instead of sets in several places; I believe we'll
>       have set semantics, but in practice I think we do care about
>       order for roundtripping, so we should keep it in the object
>       model.

this I suggested to solve with the position-property.
this is also easier to handle with in the ontologization, as
for instance, in order to axiomatize fixed/limited arity of terms in a 
language can be axiomitized easily with the positional properties, 
whereas with the lists you need a builtin to compute the length of the 
list... not impossible but seems nasty.

>     - we made Equals use a list instead of just two elements, to be
>       more in-keeping with And, etc.

looks as if makes sense, but the issue with the lists worries me a bit, 
as mentioned above, in terms of axiomatization of an ontology of 
dialects. However, depends all on how deep we wanna go with that.


[1] http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0105

Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/
Received on Thursday, 8 February 2007 00:48:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:42 UTC