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

Yes, I agree. This  isLiteralOfType does not really give much flexibility and,
in fact, may cause some headache when you supply wrong values in the type
argument.

Actually, this problem is intrinsic to isLiteralOfType. The same is true
for rif:iri's as type designators.

michael


On Sun, 12 Apr 2009 14:53:22 +0200
Jos de Bruijn <debruijn@inf.unibz.it> wrote:

> <snip/>
> 
> > 
> >> 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 isLiteralInteger, isLiteralString, 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
> 
> 
> Like I said earlier, I can live with this solution.
> I wonder, though, what the real advantage is compared with the
> individual guard predicates.  Sure, you don't have to specify the "short
> names" the datatypes and have a little bit more flexibility, but not all
> that much.
> The thing is that this predicate cannot be as flexible as one might
> expect.  Particularly, we need to restrict the domain of the second
> argument to the anyURIs of known datatypes (at least, there cannot be
> anyURIs in the domain beyond the ones that are known to identify
> datatypes), in order to prevent invisible extensions [1].  This means
> you cannot use isLiteralOfType to "extract" the datatypes of literals.
> 
> Consider the rule
> 
> myType(?x) :- External(isLiteralOfType("1"^^xs:int, ?x))
> 
> Now, if the variable ?x is assigned to ".....decimal"^^anyURI,
> isLiteralOfType("1"^^xs:int, ?x) is true.  However, if ?x is assigned to
> "http://bla"^^anyURI, the predicate is assigned an arbitrary truth
> value.  So, if the RIF implementation is adopting good practice, it will
> return an error when executing this rule.
> 
> So, in practice, you are limited to using constants as the second
> argument, or a very limited form of quantification.  For example, you
> could do something like this:
> 
> numericType("...decimal"^^xs:anyURI)
> numericType("...double"^^xs:anyURI)
> numericType("...float"^^xs:anyURI)
> 
> myPositiveNumber(?x) :- And(numericType(?y)
> External(isLiteralOfType(?x,?y)) External(greater-than(?x, "0"^^xs:int)))
> 
> Here, you extract all positive numbers, regardless of whether they are
> decimals, doubles, or floats.
> 
> As a reference, here's what this rule would look like if we had
> individual guard predicates:
> 
> myPositiveNumber(?x) :- And(Or(External(isLiteralDecimal(?x))
> External(isLiteralDouble(?x)) External(isLiteralFloat(?x)))
> External(greater-than(?x, "0"^^xs:int)))
> 
> 
> 
> 
> Jos
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Apr/0047.html
> 
> 
> > 
> > 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 Sunday, 12 April 2009 17:00:57 UTC