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

Jos de Bruijn 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].

The dialects are already parameterized by the set of datatypes, just as 
they are by the set of externals, I don't see this as an "invisible 
extension".

>  This means
> you cannot use isLiteralOfType to "extract" the datatypes of literals.

Are you saying this just because of binding patterns?  I assume that 
once this question is settled, and especially if we end up using 
xsd:anyIRI for isLiteralOfType, then we'll give it the binding pattern 
(b,u).

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

Fine.

> So, in practice, you are limited to using constants as the second
> argument, or a very limited form of quantification. 

Or an unbound variable.

Dave

Received on Monday, 13 April 2009 08:36:06 UTC