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

On Fri, 10 Apr 2009 10:20:29 +0200
Jos de Bruijn <debruijn@inf.unibz.it> 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.

I don't see this as a huge deal: after all, these are two languages, and things
aren't going to be completely smooth at the seams.


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

I think here philosophy should be put aside and we should just use anyURI ro
specify the data types in isLiteralOfType

michael


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


-- 
    -- michael

Received on Friday, 10 April 2009 17:47:26 UTC