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

>>>> 6- section "symbol spaces" second paragraph, first sentence: symbol
>>>> spaces are actually not subsets of the constant symbols in RIF.  First
>>>> of all, a symbol space is not a set; second, constant symbols are pairs
>>>> (literal, symbol space IRI). I would propose to rephrase this sentence
>>>> to something like "every constant symbol in the RIF as an associate
>>>> symbol space"
>>> They are named subsets. (I added "named" to their abstract definition).
>> they are not subsets, because symbol spaces are pairs of lexical spaces
>> and identifiers
> 
> Symbol spaces are defined as subsets of the set Const of all constants.

I was thrown off by the phrase below the definition, which says "Each
symbol space is described through its lexical space and its
identifiers.", which appears to be a definition.
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.


>>>> 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).
>> This does not yet address my concerns about the impedance mismatch
>> between the equality symbol on the one hand, and predicate symbols on
>> the other: Predicate symbols are interpreted as sets of tuples, whereas
>> equality is interpreted as identity.
> 
> 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.

> 
> 
>>>> 3- section "symbol spaces": why is the lexical space of the symbol space
>>>> non-empty?  Why not simply define it as a set?  I think it does not hurt
>>>> to allow empty lexical spaces.
>>> 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.

> 
> 
>>>> 4- section "symbol spaces": there should be a restriction on the kinds
>>>> of datatypes which may be used.  Namely, the lexical-to-value mapping
>>>> and the value space need to be well-defined;
>>> what do you mean by that?
>> Say, you are using a datatype with an ill-defined value space, e.g.
>> xsd:duration.
>> If you have a symbol "xx"^^xsd:duration, the value
>> IC("xx"^^xsd:duration) is not well defined, so the interpretation is not
>> well defined.
> 
> "xx"^^xsd:duration is *not* a constant in rif.
> I guess you are talking about "unknown" symbol spaces. In that case tey are
> not going to be treated as data types and their value space will not be defined.
> It is an omission in the semantics section (now fixed). 
> 
>>>> now, the RIF
>>>> semantics is not well-defined. The text in the paragraph "symbols with
>>>> ill-formed lexical parts" will then need to be updated accordingly.
>>>> 5- "symbols with undefined symbol spaces": the description in this
>>>> paragraph is incorrect, since, if the symbol space corresponds to a
>>>> known datatype, and implementation will interpret the symbol according
>>>> to this datatype.  I propose to remove this paragraph.
>>> You were the one who proposed this paragraph in the first place. 
>> That was when the datatype support in the RIF was not yet extensible.
>> Now it is, so the paragraph is out of date.
> 
> I do not understand that. In fact, I now added another paragraph about
> unknown spaces in the semantic section.
> 
>>> Second, I
>>> do not really understand what you are saying.  The paragraph you are
>>> referring to talks about "undefined" symbol spaces, while in the above you
>>> are talking about the known spaces.
>> yes, the terminology is a bit confusing.  RIF "defines" a number of
>> symbols spaces, but people can use additional symbol spaces which
>> correspond to /known/ datatypes.
>> So, we have a number of symbol spaces defined by the RIF; of these
>> symbol spaces, those which corresponds to datatypes, correspond to
>> /known/ datatypes (by definition). There are a number of other symbol
>> spaces which corresponds to datatypes.  Some of these will correspond to
>> known datatypes, and some will corresponds to unknown data types.
>> I interpreted an "undefined" symbol space as a symbol space which is not
>> "defined" by RIF.
> 
> This is something I fail to understand. What is a known but unsupported
> data type? We list the data types that are known and supported and all the
> rest are unknown and unsupported as far as RIF is concerned.
> 
> You cannot build an implementation of a logical system based on some
> undefined or unknown concepts.

I had written my comments under the assumption that we agreed to make
datatype support in the RIF extensible.  Clearly, we both understood
something different from this agreement.

The way I see extensibility of data type support, we should allow the
use of data types which are not supported by RIF, but which are known by
the agent processing the RIF descriptions.  And with "use" I mean that
the RIF semantics should allow to derive equalities which follow from
such datatypes.
As Dave pointed out in the face-to-face, RDF and OWL implementations do
not seem to have a problem with this kind of extensibility.


(I am sending a proposal for a text which facilitates this in a separate
e-mail)

> 
> 
>> By the way, it is exactly this confusion which led me to propose to use
>> datatype maps.  Interpretations will be defined with respect to a
>> datatype maps, which includes all the /known/ datatypes.
> 
> Data type maps is one of the most confusing and ill-defined concepts that I
> came across.

I do not really see what is confusing or ill-defined about datatype
maps.  A datatype map is simply a mapping from URIs to data types.

> 
> 
>>>>    a- it is hard to grasp from the definition how a single constant
>>>> symbol is interpreted; it is necessary to carefully read and try to
>>>> understand all the (too lengthy) text. The definitions can be much
>>>> crisper, as I showed in earlier proposals for this definition.
>>> I do not think that the text is either lengthy or that it is not crisp
>>> enough.
>>> I believe that this is similar to your earlier proposals. If you have a
>>> specific text to propose, please do so.
>> OK, I will send a proposal in a separate e-mail.
> 
> Please take into account the recent updates.
> 
>>>>    d- no distinction is being made between the identifier of a symbol
>>>> space and the symbol space itself, whereas they are different things
>>> Where did you find that?
>> For example, you talk about things like "the symbol space rif:text".
>> However, rif:text is the identifier of the symbol space, and not the
>> symbol space itself.
> 
> Well, this is quite acceptable. People do this all the time when confusion
> does not arise. I was asking about the places where the use of "the symbol
> space rif:text" as opposed to "the symbol space *named* rif:text" causes
> confusion.

OK.
I would propose to add a phrase like "In the remainder  of the document
we use the identifier of a symbol space to denote that symbol space."
when introducing symbol spaces.

> 
> 
>>>>    e- according to the second bullet in "the effect of the symbol
>>>> spaces", the mapping IC(lit^^symsp) should be defined for every constant
>>>> symbol of the form lit^^symsp with lit in the lexical space of the
>>>> symbol space identified by symsp.  This would mean that every such
>>>> symbol is in the vocabulary of every RIF language. I think this is
>>>> highly undesirable (and should have been mentioned in the syntax
>>>> section). The mapping should only be defined for symbols in the vocabulary.
>>> We are defining a logic, including some specific sets of symbols that
>>> belong to the language of that logic.
>> Yes, but it is not necessary.  Why not let the user decide exactly which
>> of the symbols to use?
> 
> The user can use or not use whatever symbols they want. This has absolutely
> no effect on the user! When you define a language of a logic, you are
> defining a language for that logic, not for a particular set of formulas in
> that logic. This is a standard textbook way of doing things.

In most text books, papers, and standard specifications I read
(including your own paper [1]) this is not the way of doing things.
The usual definition of a logic looks something like:
Given some set of symbols A ( i.e. vocabulary/alphabet/signature ), the
language LA is the set of formulas constructed using the symbols in A
and the logical connectives.......

I don't really understand why we should do something different.


[1] Michael Kifer, Georg Lausen, James Wu: Logical Foundations of
Object-Oriented and Frame-Based Languages. J. ACM 42(4): 741-843 (1995)

> 
> 
>>> Your claim that this is "highly undesirable" requires at least some explanation.
>> OK, because it is syntax my claim is probably a bit too strong.  The
>> thing is that it is simply unnecessary to include all these constants in
>> the vocabulary of every language, so why would we do it?
> 
> See above.
> 
> 
>> An additional drawback is that if we were to consider a dialect which
>> has a semantics based on Herbrand universes, all these symbols are
>> included in the universe. This would have certain undesirable
>> implications, e.g. ( considering a dialect with negation):
> 
> You are completely wrong. Herbrand universes are defined with respect to
> the symbols mention of the rule set, not with respect to the symbols in the
> entire logic language.

There are certainly papers where the Herbrand universe is defined with
respect to a vocabulary (e.g. [2]), since such a definition is more
general (in the mentioned paper the symbols in the Herbrand universe
which are not in the rules are used for queries to an external knowledge
base).

[2] Thomas Eiter, Thomas Lukasiewicz, Roman Schindlauer, Hans Tompits:
Combining Answer Set Programming with Description Logics for the
Semantic Web. KR 2004: 141-151

>>>>    g- the value space is required to be a subset of the domain.  This
>>>> means that every interpretation includes all value spaces of all data
>>>> types.  This is unnecessary.
>>> So what? It makes the definition simple and uniform.
>> It makes every domain infinite. For most kinds of rules (especially
>> those without equality in the head) this is not really a problem.
>> However, as soon as we have full use of equality, or deal with
>> extensions in the direction of FOL, then one often wants to talk about
>> finite models.
> 
> You can still talk about finite models. 

How?  Every model is infinite.

> If you are not going to use
> infinite relations then you are fine. If you are going to use infinite
> relations then you do not have finite models anyway. Equality is
> never a problem in this setting, because it is interpreted as identity.
> 
>> It also makes rule sets which only contain rules such as Forall ?x,?y
>> (?x=?y)  inconsistent. I claim that this is undesirable.
> 
> I claim that this is YGWYD (you get what you deserve). Such a statement
> should be treated as inconsistent if you are using data types.
> 
> Although I do not agree with any of your arguments about undesirability, I
> am ok with changing things so that value spaces will not be required to be
> a subset. To this end, I added a note in the appropriate place stating that
> you are proposing a certain change. Let the people decide!
> 
> 
>> On a side note, some extensions (and possibly a combination with OWL DL)
>> will want to separate the (concrete) interpretation domain for datatypes
>> from the individual (abstract) interpretation domain in order to be able
>> to do effective reasoning.
>> I believe we currently do not have such a mechanism (to separate the
>> two), do we?
> 
> I am not sure what you mean.

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.


Best, Jos

> If you are not using data types then you can
> map the thing into a theory where data types are not used.
> 
> 
> 	--michael  
> 
> 
>> Best, Jos

-- 
                         debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
In heaven all the interesting people are
missing.
  - Friedrich Nietzsche