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

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, "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.
> 
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller

Received on Friday, 10 April 2009 08:21:17 UTC