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: Chris Welty <cawelty@gmail.com>
Date: Tue, 24 Mar 2009 22:20:48 -0400
Message-ID: <49C99500.8070608@gmail.com>
To: kifer@cs.sunysb.edu
CC: Dave Reynolds <der@hplb.hpl.hp.com>, RIF WG Public list <public-rif-wg@w3.org>

Thanks for bringing this up, Michael.  I had suggested in a previous telecon 
that the issue of what to use for the datatype IRI in the "isLiteralOfType" 
predicate also impacted imports, so this makes sense to me.

Regarding annotations - thinking about it I realized I'd been assuming the IRIs 
in the metadata would stand for the document, rule, or whatever peice of syntax 
it is annotating, as Dave said.  I'm not sure what other people were assuming, 
but if we agree we could make that explicit.

Of course make that explicit puts the documents/rules/whatever into the domain...


Michael Kifer wrote:
> On Tue, 24 Mar 2009 09:22:18 +0000
> Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>> 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.
> Thanx. I was aware of anyURI, but didn't know that it was expanded 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.
> An IRI string, at least, stands for itself and represents an address.
> A rif:iri constant stands for nothing. A rif:iri constant can be interpreted by
> anything, e.g., by the number 1.33333.
> In a document, such a constant could be sufficiently axiomatized so that it
> would correspond to something useful, a concrete real-life object. But in an
> annotation there is nothing that ties a rif:iri constant to anything.
> Certainly not to any particular rule.
>> 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.
> Dave, the problem is that the spec says that "the id is a rif:iri constant."
> That is, **nothing else** is allowed. This might be ok for local metadata, but
> is completely useless for metadata, which one wants to access globally.
> This is especially unacceptable, if one wants to talk about documents as
> opposed to just individual rules.
>>> 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.
> Sure. This was just out of the top of my head. Something else could be
> used to abbreviate anyURIs.
> michael

Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
Received on Wednesday, 25 March 2009 02:21:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:54 UTC