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

Jos wrote:
>
> >> I would propose to rephrase it to something like "Each symbol space has
> >> an associated lexical space and a number of identifiers."
> >> Furthermore, I would propose to start the definition of symbol spaces on
> >> a new line, rather than in the middle of a paragraph.
> >> Finally, I would prefer it if it is written explicitly what this subset
> >> of Const, which is the symbol space, actually looks like (i.e. a set of
> >> pairs).  I think it is more readable if this is spelled out, rather than
> >> it being implicit in the text.
> > 
> > OK. I made the changes that you suggested. I do not quite see how to
> > implement your last suggestion without making the sentence look bad.
> > If you have a concrete suggestion, please send it to me. Take a look at how
> > it looks now.
> 
> A possibility would be (notice that I removed the word "just", which
> seemed awkward in this sentence):
> 
> "Formally, a symbol space is a named subset of the set of all constants,
> Const, consisting of pairs of strings and symbol space identifiers."
> 
> I recognize that this sentence is not really perfect, but I don't have a
> better suggestion at the moment.


OK, done.


> >>> Equality is a set of tuples -- it was just defined differently, but
> >>> equivalently. I'll change its definition so that it will look like a normal
> >>> predicate. But it is a good point. Other than that, would =^^rif:local
> >>> satisfy your objection? (I already did it).
> >> I would prefer = to be a special symbol in the language, rather than a
> >> predicate symbol with a special interpretation.
> >> However, I can live with the current definition.
> > 
> > 
> > Why should it be a special symbol when it is just a predicate?
> 
> This is where our points of view differ; I do not see it as a predicate
>  symbol. But, anyway, I can live with it being described as one.


I actually also do not care that much. But formally = is a predicate (or is
equivalent to one).


> >>>>> A symbol space defines a set of constants. If the lexical space is empty,
> >>>>> the set of constants is empty. Does not make sense to contemplate such sets
> >>>>> of symbols in the syntax, IMO.
> >>>> Well, I can easily think of cases where one would want an empty symbol
> >>>> space. I can, for example, easily imagine rule sets which do not use any
> >>>> local identifiers, so the lexical space of the rif:local symbol space
> >>>> will be empty.
> >>>> furthermore, the definitions just become more complicated by requiring
> >>>> the sets to be nonempty.
> >>> The lexical space of rif:local is never empty. It is defined by RIF in a
> >>> concrete way.
> >>> Does not matter if a particular rule set or language uses that or not.
> >>> There is no side effect.
> >> This doesn't address my point about definitions becoming more
> >> complicated.  I simply don't see why we would need such a requirement.
> > 
> > And I do not see why should we allow things that make no sense.  Why do we
> > need to even consider allowing empty named subsets of the overall sets of
> > constants?
> 
> Allowing is not the additional burden here.  Disallowing is the
> additional burden. So, again, I don't see you real reason for including
> this additional requirement.
> In any case, I guess it is not a big issue, so I won't object to the
> current text.


I do not see where is the burden. It is like saying that we should allow
the set of constants to be empty because stating otherwise is an additional
burden. The point is that empty symbol spaces just do not make any sense.
Our language is supposed to capture certain phenomena, and capturing empty
sets of constants is not our intent.


> > The standard way is to first define an alphabet (which includes all the
> > symbols, connectives, etc.) and then define the rules for putting the
> > alphabet symbols together into formulas.  This is not explicitly mentioned
> > -- an omission. It is mentioned now. In fact, there was a bad typo, which
> > said "The language of RIF ..." while it should have been "The alphabet of
> > RIF ...".
> 
> As I understand, the standard way is to let the alphabet vary; the user
> can choose an alphabet, and the logic defines which formulas can be
> obtained from this alphabet and the logical connectives (i.e. the
> language). in my example above, the alphabet A is chosen by the user,
> and LA is the language obtained from A and the logical connectives and
> syntax formation rules in logic.

Nope. When you define a logic, you would normally say that you have a set
Const, Var, etc., without giving out many details.

But when you are specifying a ***concrete language*** then you must state
what your alphabet is, and it is fixed. An analogy is to say that Java
should not have a fixed alphabet and each user should be able to decide
which sequences of characters are to be allowed as variables, integers, etc.

We are defining a concrete language, not just a logic.

> Normally, the two different ways of defining an alphabet (fixed versus
> varying) would not make much difference.  However, because we have data
> types which require the fixed interpretation of certain constants, the
> choice between the two has certain semantic consequences.
> 
> However, since I am no longer resisting against the value space being a
> subset of the domain (see below), I guess it doesn't really matter in
> the end.
> 
> > You need to look at the relevant parts of the models, which would be finite.
> > 
> > If you want data types, then their symbols are part of the alphabet. If
> > they are, the universe is infinite. You are trying to introduce something
> > quite non-standard to bend the definitions to look in a nonstandard way
> > because of your personal aesthetic views.
> 
> OK, I am convinced :-)
> I agree now that value spaces should be subsets of the domain.

Good!


> >> In Description Logics, a distinction is made between the abstract domain
> >> and the concrete domain. The value spaces of data types are subsets of
> >> the concrete domain.
> >> Each predicate symbol has a signature (e.g. abstract x abstract or
> >> abstract x concrete) which determines which kind of symbols can be used
> >> there.
> >> Data values are interpreted in the concrete domain, and variables
> >> quantify either over the abstract or over the concrete domain.
> >>
> >> Because of this strict separation between the abstract and concrete
> >> domains, reasoning with data types in Description Logics can be done
> >> through issuing conjunctive queries to a datatype oracle.
> > 
> > So, take U minus the value spaces of data types, and this is your abstract
> > domain.
> 
> The question is: how can you make sure that certain variables quantify
> only over this domain?

You need sorted variables for that. Descr logics have precisely that
(although they do not call it this way because this is a very simple use of
sorts that they have).

I do not object to introducing variables that range over subdomains, but a
few months ago we made a decision against that :-)


> > You are splitting hairs. Nah, you are arguing about something that
> > is even less interesting than splitting hairs. :-)
> 
> I do not agree that this question is not interesting, since it impacts
> OWL compatibility and possible DL-inspired dialects.
> However, since it does not yet clear what the impact will be, let's
> shelve this issue until we learn more (about OWL compatibility).

Exactly. Let's first see if there are incompatibilities in the first place.


	cheers
	  --michael

Received on Tuesday, 16 October 2007 16:44:42 UTC