Re: Diatribe on why rif:iri consts should be left alone

Dave Reynolds wrote:
> Surely the extensibility argument could equally well be applied to the
> predicates and functions in DTB. Those are denoted by rif:iris and we
> are giving them a fixed interpretation, at least as externals.

It is precisely because of the extensibility issue that we require
External() to be written around external predicates and functions. If
the name, say, func:string-join is used outside External(), it is simply
an uninterpreted symbol, and DTB has nothing to say about it.


> One way round the extensibility issue is reserved namespaces, to suggest
> that rulesets should avoid use of xs:* and rif:* IRI constants since
> those might be assigned interpretations in future dialects.
> Dave
> Jos de Bruijn wrote:
>> To reiterate my position here: I do not find the kludginess argument
>> very compelling, but I do share Michael's concerns about extensibility.
>>  In fact, adopting my earlier proposal would violate the extensibility
>> principles we set up in RIF, and I believe we documented it in some
>> resolution: if X is a ruleset in dialect A and dialect A' extends A, X
>> should have the same entailments under both A and A' semantics.
>> Now, the solution proposed by Michael below introduces special constants
>> for denoting the datatypes.  The problem with this, as noted by Dave, is
>> that when combining the RIF rules with RDF or OWL, you used two kinds of
>> constants to denote the same datatype, e.g., in such combinations
>> "http://...string"^^rif:special and "http://...string"^^rif:iri would
>> both denote the string data type.  I consider this undesirable.
>> Therefore, the least of all evils seems to be to revert back to
>> individual guard predicates for the datatypes, i.e., instead of
>> isLiteralOfType we would have isInteger, isString, etc.
>> I believe we do have sufficient grounds to override the previous
>> resolution that established isLiteralOfType, because we did not realize
>> at the time that it would cause so many problems.
>> Jos
>> Michael Kifer wrote:
>>> I was asked at the last telecon to document the problems with
>>> assigning special
>>> status to some RIF IRIs, like those that happen to have names that
>>> happens to
>>> point to data types.
>>> The problems are extensibility + kludginess.
>>> 0. Background.
>>>    Unlike the data type constants, rif:iri and rif:local constants
>>> have no
>>>    particular meaning in RIF. Their interpretation varies from one
>>> semantic
>>>    structure to the next. They are intended to be used as object
>>> names whose
>>>    properties are axiomatized by sets of facts and rules provided by
>>> the user.
>>>    Eg, <http://...john> means nothing. If we want it to mean something,
>>>    axiomatize it:
>>>    <...john>[name->"John" address->"1 Main St., USA" born->"1999-1-1"]
>>>    etc. Similarly, xs:string means nothing. It just happens to have a
>>>    particular name. Likewise, ""^^rif:local
>>>    means nothing (in fact, no less than xs:string).
>>>    Jos' proposal: force some such constants to have fixed
>>> interpretation, like
>>>    the data types do. The criteria for this choice are pretty
>>> arbitrary: if a
>>>    constant happens to be mentioned in some documents (eg, XML
>>> schema), it must
>>>    be forced to have some special interpretation. The set of these
>>> documents is
>>>    not closed, as RIF dialects are free to define new data types. In
>>> fact, why
>>>    only data types? Why not postulate that from now on the constant
>>>    <> has a fixed interpretation?
>>> 1. Extensibility.
>>>    If we allow some rif:iri to have different semantics then there is
>>> a problem
>>>    with extensibility. To see that, consider dialects A and  B. Let
>>>    B be a proper syntactic and semantic extension of A except for one
>>> little
>>>    thing: B assigns some special meaning to a rif:iri constant <foo>,
>>> while A
>>>    does not.
>>>    Now, B receives a document, D, that falls in dialect A (eg, BLD).
>>> Suppose
>>>    D uses <foo> as an object name for some concept foobar (eg., New
>>> York City).
>>>    And why not? it is not written on this <foo>'s forehead that it is
>>> special to
>>>    some dialect B. However, B cannot evaluate the document D
>>> according to the
>>>    BLD's semantics, since B is interpreting <foo> specially, as New
>>> York City
>>>    (or, more prosaically, as some fancy data type).
>>> 2. Kludginess.
>>>    This creates special exceptions for some constants, which complicates
>>>    definitions for no reason. What this does is that it essentially
>>> introduces
>>>    a new type of constants through the back door. We introduce a new
>>> domain for
>>>    them, but don't distinguish them syntactically. So, there is no
>>> way of
>>>    knowing if any particular symbol is or is not special unless you
>>>    read a tedious manuals.
>>> A proper solution for this is to have a different symbol space, say
>>> rif:special. Its lexical space could be the same as rif:iri, but the
>>> domain
>>> would be different. For the known data type constants, the
>>> interpretation would
>>> be what Jos wants. For others, it will be what each particular dialect
>>> decides. This way:
>>> i.  No extensibility problems: a rule set in a particular dialect
>>> won't be
>>>     allowed to use special constants that that particular dialect
>>> does not
>>>     define. For instance, BLD documents cant use "foo"^^rif:special
>>> so there is
>>>     no problem.
>>> ii. No kludges: there are no exceptions---every symbol space has its
>>> purpose
>>>     and is treated uniformly.
>>> My earlier proposal was even simpler: why not simply use anyURI. The
>>> philosophical issue that anyURI constants denote URIs and not data
>>> types seems
>>> to me to be a topic for a dinner discussion for the philosophy folks.
>>> But, in
>>> any case, rif:special is always there for us to do the right thing.

+43 1 58801 18470

Jos de Bruijn,
Many would be cowards if they had courage
  - Thomas Fuller

Received on Friday, 10 April 2009 11:07:10 UTC