Issues with rif:iri in a number of places in the spec

I discovered several semantic issues with our use of rif:iri in BLD and other
docs. The problematic uses are:

   1. As ids in the annotations.
   2. In the Import directive


The problem is that rif:iri constants are not really IRIs, but are
uninterpreted constants that can stand for anything. In particular, they can
mean different things in different documents. For instance, if some document
is identified by a rif:iri constant <foo>, it really means nothing. If I
want to refer to that particular document in two other distinct documents, I
cannot do that using the rif:iri constant <foo>, as in one document this can be
equal 1 and in another to "abc", and in none it has anything to do with the
actual IRI foo.

The problem with Import is related to that. In addition, in Import we are using
rif:iris, but in Base and Prefix IRI strings, which is an arbitrary
inconsistency.

Solution:

  For Import, we could also use IRI strings, but this is not the solution that
  I favor. I prefer to use something like anyIRI. I don't know if this data
  type exists (could not find it), but we can define it as rif:anyIRI.
  rif:anyIRI constants would be interpreted by unicode strings that have the
  form of an IRI (in contrast to rif:iri's, which can be interpreted by
  anything in the domain).
  Once we have that, I would propose to change the iri strings in Base, Prefix,
  and Import to use rif:anyIRI (or whatever we decide to name it).

I further propose to extend our Curie notation to support
rif:anyIRI constants. Maybe use <foo:bar> for rif:iri's and foo:bar for
rif:anyIRI's.

A related problem was discussed several weeks ago and was never resolved: what
to do with http://www.w3.org/2005/rules/wiki/DTB#pred:isLiteralOfType
The second argument is said to be a rif:iri constant, which makes no sense
semantically, and Jos was seeking to change the semantics just to
accommodate this one builtin.

michael

Received on Tuesday, 24 March 2009 06:10:17 UTC