Re: comments on current version BLD document: symbols, datatypes, semantics

> Igor Mozetic wrote:
> > 
> > Michael Kifer wrote:
> > 
> >>> 2- section "signatures and a condition language of RIF^BLD^": the
> >>> definition of equality atoms is not entirely clear: the symbol = is not
> >>> a constant symbol in RIF, according to the syntax definition in section
> >>> "presentation syntax" (it does not have the symbol space).  Furthermore,
> >>> as it is correctly mentioned that equality is not a built-in predicates,
> >>> I feel there is an impedance mismatch between this predicate symbol and
> >>> all other kinds of predicate symbols.  Finally, equality is currently
> >>> not mentioned when atomic formulas are initially defined.  Therefore, I
> >>> would propose to define equality atoms a=b directly when first defining
> >>> atomic formulas.
> >>
> >> A good point! You were looking at a version before I moved = further 
> >> down,
> >> but the point about its symbol space is well-taken. It should be either
> >> rif:local (my pref) or rif:iri.
> >>
> >> I experimented with requiring all symbols to have explicit symbol 
> >> spaces in
> >> the examples, but I think they become unsightly due to that. Perhaps we
> >> should not require ^^rif:local explicitly. Then we could write a=b as
> >> before.  If people think that we should insist on explicit symbol space
> >> names (as it is done now, to make the syntax look more abstract and 
> >> devoid
> >> of syntactic sugar) then I am fine with writing a =^^rif:local b or even
> >> equal^^rif:local(a,b).
> >>
> > 
> > I would prefer to drop explicit ^^rif:local.
> > Otherwise, the presentation syntax becomes really difficult to read.
> 
> This is supposed to be a web based interchange language. If anything 
> perhaps the short cut should be for rif:iri and the examples should use 
> curie format IRIs rather than rif:local unless there is a compelling 
> reason for them to be local.

I think that in most cases people will actually use rif^^local.

Also, the presentation syntax is for *our* examples. It is not a concrete
syntax. So, the concern should be that our documents will look nice.


	--michael