- 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>
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.
--michael
Received on Friday, 13 June 2008 17:26:44 UTC