Re: Action 299 - removing sorts

Dave,
thanks a lot for the comments. I've fixed the typos, which you found.
Other answers are inline below.

> Michael Kifer wrote:
> > http://www.w3.org/2005/rules/wg/track/actions/299 has been completed.  Part
> > of the title of this action says: "handle datatypes as in RDF."  This was
> > *not* what was resolved at the F2F and was put in there by mistake (I
> > hope).  Certainly, I would not have agreed to such an action, since I do
> > not know what this might mean in logic.
> > 
> > Other than that, the main changes are in 
> > http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions
> 
> Thank you.
> 
> The approach of using signatures to control well-formedness and having 
> default signatures inferred for Core conditions makes sense to me.
> 
> Unless I'm missing something there is nothing in that section concerning 
> typed literal data values. There seems to be no mention of them in 
> either the abstract syntax or the semantics, just a list of xsd types at 
> the front.  Is that material now somewhere else or is it work in 
> progress or am I just blind? [*]

The ^^ syntax is mentioned in the BNF. For the abstract syntax,
Harold will hopefully fix it. I am still not very good at it.

This has nothing to do with my questioning the "like RDF datatypes" part.
I just do not know what this "like RDF" thing entails. On the other hand,
defining data types as subsets of the overall set of symbols is simple and
I plan to add it if we decide that the current direction is fine. It is
quite possible that what will come out will correspond to what Sandro (and
perhaps you) had in mind when he wrote "like RDF datatypes".


> Similarly whilst the introduction says that IRIs are used to refer to 
> individuals, predicates and functions the abstract syntax doesn't yet
> support that.  [Reasonable at this stage, I'm just noting it so we don't 
> forget it.]

Yes, this needs to be decided upon. My original approach was to introduce
the sort of rif:iri's. Now we do not have sorts, but we can still have iri
symbols.  They will be either denoted using the ^^rif:iri syntax or will be
strings that look like IRIs. I think the former should be the case, but I
was not clear what the group wants. In particular, Jos had a proposal,
which I did not understand.

In connection with this, we need to decide on how signatures are attached
to data types. For instance, should we say that strings, dates, times,
integers, etc., can be only individuals or we should not place any
restrictions on them?

Since there is a strong sentiment that not everything should be a URI,  
the question is whether there is anything meaningful to say in the logic
about the rif:iri data type.

> Minor detail but the section "Signatures in the concrete syntax" seems 
> out of place. It should have an abstract syntax instead of (or perhaps 
> as well as) an example concrete syntax and probably needs its own 
> subsection.

Why is it out of place? We need to explain how signatures are defined.
But since the material in that section is more general than just the core
horn, perhaps you are right that it should be a section on its own.


> I happened to notice some minor typos recorded below for completeness [**].

Done.


	cheers
	  --michael  



> Dave
> 
> [*] I realize this is correlated with your rejection of the part of the 
> action concerning handling datatypes "in the same way as in RDF" but I 
> can't tell form your discussion with Sandro what your alternative is and 
> what it's status is.
> 
> [**] Trivial typos
> 
> (1) In the line:
>      σ0 has an arrow expression of the form (σ1# ... σ1#) → σ#
> presumably that should be: (σ1# ... σn#) → σ#
> 
> (2) Under well-formed formulas, two ψ are missing the trailing ;
> 
> (3) In "Signatures in the Core RIF Condition Language" the predefined 
> boolean signatures are labelled bn whereas the rest of document uses pn.
> 
> (4) In "Signatures in the concrete syntax" there is an unclosed 
> fixed-width font shift after "..Const and Var.".
> 
> -- 
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
>

Received on Tuesday, 17 July 2007 12:16:09 UTC