W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

Re: ISSUE-61 (IRI-Casts): Casting to/from rif:iri [DTB]

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Fri, 13 Jun 2008 13:25:42 -0400
To: Axel Polleres <axel.polleres@deri.org>
Cc: Jos de Bruijn <debruijn@inf.unibz.it>, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>
Message-ID: <20080613132542.47621660@cs.sunysb.edu>

On Fri, 13 Jun 2008 13:19:06 +0200
Axel Polleres <axel.polleres@deri.org> wrote:

> >> If I understood michael correctly, the other direction
> >>
> >>   rif:iri("b"^^xsd:string) = "b"^^rif:iri
> >>
> >> can still work, yes?
>  >
> > I see no technical problem with it.
> ... so, it *is* a function then, right? in the rif:iri direction, i 
> mean, it is just that the definition is slightly different than the
> other built-in functions.

Yes, theoretically it is probably ok.

> >> At least that would save the casts *to* rif:iri, and we only need the 
> >> predicate for  string-to-iri ... yes?
> > 
> > It seems to me that this just complicates matters; users need to learn 
> > both the predicate and the "function", which probably doesn't really 
> > behave as they expect.
> *users* don't need to learn anything new, they can use cast functions 
> just like for data types, which is intuitive. If we add new predicates, 
> they need to learn something new, this is why I want to keep functions 
> for conversions wherever possible.

For logic-based dialects with function symbols this is not a problem.
But for PRD and others it might be a problem, since they can use only
1-directional functions and so cannot cast back (from IRIs to strings, the
non-unique direction). Dialects that do not support equality will also be hit.

Received on Friday, 13 June 2008 17:26:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:45 UTC