Diatribe on why rif:iri consts should be left alone

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, "http://w3.org/..../string"^^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
   <http://www.newyork.com/> 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.


-- 
    -- michael

Received on Friday, 10 April 2009 04:59:08 UTC