Re: working on it (RDFS - if/iff)

On Thu, 2003-06-26 at 06:00, Jeremy Carroll wrote:
> (escaped early)
> 
> Pat
> 
> we still have to *decide* whether we want to go the way in the documents you
> produced last week, or along the lines of the after hours conversation.

I agree that we need to decide...

DanBri, Graham, Jan, Mike Dean, everybody: please let's
make this decision consciously. Please form an opinion
and let us know.



I can't find any rationale for the iff choice, other than it's
what was in the last call
spec. I find the lack of a proof of completeness of the rules
evidence of unnecessary complexity. *Why* does anybody
want rules 12a/12b?

I think this confirms the simplicity of the 'if' design:

[[
In this, *all* the RDF/S semantic conditions are 'if' not 'iff', so 
the correspondence to the rules will be easy to establish, and the 
relevant closure lemmas easy to prove. [...]

The complete RDFS rules are now rdfs 1, 2, 3,4a,4b,6, 7a, 9,10,11; 
the correspondence to the semantic conditions is very clear.

[...] Thus, the overall content will be similar to the last 
version except that a simple basic RDFS rule set can be complete and 
included in the normative spec [...]
]] -- PatH, in the message that started this thread.


I tried to find a WG decision that might shed some light
on why the WG chose iff vs. if semantics, but I couldn't find one,
save the decision to go to last call, which confirmed all the
things we delegated to the editor. I don't think the WG
has a considered opinion on the matter.

I did some spelunking in the WG records...

  on RDFS semantics of subClassOf, range, etc.
  posted by DanC at 2003-06-25 19:04 (+)
  http://rdfig.xmlhack.com/2003/06/25/2003-06-25.html#1056567891.734487

and I noted hesitation about if vs. iff by
Jan in one of his reviews:

"- iff conditions on subClassOf, subPropertyOf are extensional, not
	intensional. Just a note, no fix required."
  -- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jan/0003.html

and by myself earlier...

"DanC    hmm... I have a concern about this IFF stuff, but I'm not sure what
it is."
  -- http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Oct/0386.html

I now know what the concern is: the iff stuff doesn't fit inside
horn rules. You can say "If for all ..., then ..." in a horn
clause.

If you axiomatize the iff semantics, it looks like:

all SUB SUPER (
 rdf(SUB, subClassOf, SUPER) 
   <-> 
  (all INSTANCE (
    (rdf(INSTANCE, type, SUB) -> rdf(INSTANCE, type, SUPER))
  ))

).

and that can't be reduced to horn clauses.
(ask otter yourself, if you like).


> Personally, on relfection, and on consulation with my colleagues, I prefer
>   the earlier version with iff conditions.
> 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0160
> [[
> It seems like rather a big change to make at this late stage. Would you be
> confident there weren't other properties that need to be declared by fiat
> that haven't yet been identified?
> ]]

None of the properties *need* to be declared by fiat.
Each of them is a design choice.

> [[
> These rules may be a nuisance but they are not a major obstacle.
> They don't look difficult or expensive to implement.
> 
> Given that the result of the rewrite would be, in some sense,
> less clean I would think it would need some additional motivation than just
> moving a couple of obscure rules slightly further down in the appendix.
> ]]

In what sense would it be less clean?!?!?

> Further, every entailment rule with an rdfs:subPropertyOf or rdfs:subClassOf
> on the RHS is using the extensionality of these properties.

I see them as defining the extensionality constraints, not using them.

>  i.e. six of the
> thriteen rdfs rules in the last call version. I think that that suggests that
> the extensionality is an important aspect of these properties even from a
> rule perspective.
> 
> Dan argued that given a bug is it obvious whether we fix it by fixing the
> entailment rules or fixing the model theory - he argued that it was not.
> 
> Continuing on the programming metaphor, given a bug, it is usual to try and
> preserve the contract with the user, and to only change that contract when
> the bug shows that it was a bad contract. The contract we have agreed is a
> model theoretic contract;

I don't think the WG has a clear considered opinion on that.
Yes, in going to last call, we confirmed the text that had
the model theory normative and the rules informative.
But can you point me to a WG decision that actually says
"we're going to make a model theoretic contract with
the users"? I don't think the WG expects the users to
grok model theory.



>  the extensionality contract is easier to understand
> than one with the special aspects of subClassOf and subPropertyOf declared by
> fiat;

Hmm... I can see how at some level it might seem easier to understand.
But I don't think the consequences of it are easier to understand at
all. I don't see any motivation for going outside Horn logic.

>  horst-01 does not indicate in the slightest a bug with the contract,

I disagree. A big part of the RDFS contract, for me, is:
if you grok horn rules, RDFS fits on the front side of one page.

It's a design principle we never wrote down, but we didn't really
spend much time on design principles, requirements, or any
of that stuff.


> merely a bug with the implementation. In such a case the contract should be
> preserved and the implementation fixed.
> 
> Admittedly if these rules were difficult to implement we might want to think
> again - but they are not, they are just surprising.
[...]



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 26 June 2003 11:43:09 UTC