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

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.

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

Received on Friday, 10 April 2009 11:03:33 UTC