W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

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

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Sun, 12 Apr 2009 13:52:38 +0200
Message-ID: <49E1D606.4060408@inf.unibz.it>
To: Gary Hallmark <gary.hallmark@oracle.com>
CC: kifer@cs.sunysb.edu, RIF WG Public list <public-rif-wg@w3.org>
Yes

Gary Hallmark wrote:
> and also isNotInteger, isNotString, etc.?
> 
> 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, "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 Sunday, 12 April 2009 11:53:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:04 GMT