W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

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

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Tue, 24 Mar 2009 09:22:18 +0000
Message-ID: <49C8A64A.4090000@hplb.hpl.hp.com>
To: kifer@cs.sunysb.edu
CC: RIF WG Public list <public-rif-wg@w3.org>
Michael Kifer wrote:
> 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.

It does exist - xsd:anyURI. In XML Schema 1.0 this denotes URIs but in 
XML Schema 1.1 it is extended to IRIs.

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

Using xsd:anyURI possibly makes sense for imports.

I don't think it works for annotations.

Surely the point of the annotations is that they denote the rule (or 
rule fragment) being annotated not a particular physical document 
location. It just a useful convention to reuse a location IRI, when it 
exists, for that denotation but there is no formal requirement for this.
Which is precisely what a rif:iri is appropriate here.

Another way of saying the same thing ...
I want to interpret the rule annotations as RDF metadata. The subject of 
those metadata statements is not a document or the address of a document 
it is a rule denoted by some arbitrary IRI. Whereas if the Rule IDs were 
changed to xsd:anyURI then the rule metadata would say things like:

   "http://example.com/rule1"^^xsd:anyURI  dc:author "Dave Reynolds".

which is not what is intended (and not legal RDF of course). It is not 
interesting that I might have authored that URI string, what is 
interesting is that I authored the rule which I was trying to denote by 
such a URI.

If you also wanted metadata that refers to documents, such as a place 
where you can download the original rule source then that would indeed 
be an anyURI, for example:

    http://example.com/rule1
           dc:author "Dave Reynolds";
           eg:originalSource
                 "http://dave.reynolds.net/myRules/rule1"^^xsd:anyURI .

Of course annotations have no semantic interpretation within RIF so we 
can do what we want but this use of rif:iri seems reasonable.

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

That particular notation would have confusing conflicts with the other 
specs that use Curie-like notation but I'm sure a syntax could be 
devised if needed.

Dave

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Tuesday, 24 March 2009 09:23:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:03 GMT