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: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 26 Mar 2009 15:36:55 +0100
Message-ID: <49CB9307.5000108@inf.unibz.it>
To: kifer@cs.sunysb.edu
CC: Chris Welty <cawelty@gmail.com>, RIF WG Public list <public-rif-wg@w3.org>

Michael Kifer wrote:
> On Tue, 24 Mar 2009 22:20:48 -0400
> Chris Welty <cawelty@gmail.com> wrote:
>> 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.
> Yes. I realized that we've been too liberal with naming things with rif:iri
> constants, which such constants are, in fact, devoid of any meaning.
> In fact, using rif:iri, xs:time, etc., as names for data types and symbol
> spaces is meaningless as well.

Well, unless we fix the interpretation of these particular IRI constants
(as is done in RDF).  But this is a different discussion...

>> 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.
> But these are not IRIs. These are rif:iri constants. Such a constant stands for
> nothing whatsoever unless you axiomatize it. The name of a constant has no
> relevance in logic or KR.

Well, annotations and imports have no logical meaning, so from a formal
point of view it is not a problem that IRI constants are used here.

Best, Jos

> michael
>> Of course make that explicit puts the documents/rules/whatever into the domain...
>> -Chris
>> 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

+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
Many would be cowards if they had courage
  - Thomas Fuller
Received on Thursday, 26 March 2009 14:37:57 UTC

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