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

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.

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

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

Received on Wednesday, 25 March 2009 03:48:18 UTC