Re: ISSUE-148: RDF Concepts - IRIs do *not* always denote the same resource

On Dec 15, 2013, at 4:30 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Saturday, December 14, 2013 7:54 PM, Pat Hayes wrote:
>> Possible wording compromise....
>> 
>> On Dec 14, 2013, at 8:26 AM, David Booth <david@dbooth.org> wrote:
>>> On 12/14/2013 07:04 AM, Markus Lanthaler wrote:
>>>> 
>>>>  . IRIs have global scope by design. Thus, two different appearances
>>>>    of an IRI denote the same resource. Violations of this principle
> may
>>>>    lead to interoperability problems or inconsistencies when, e.g.,
>>>>    using data from multiple sources.
>>>> 
>>>> Would that address your concerns?
>>> 
>>> That comes *very* close to addressing my concerns.  A slight tweak to
>>> the bullet item would do it:
>>> 
>>>  . IRIs have global scope by design. Thus, two different appearances
>>>    of an IRI are intended to denote the same resource. Violations
>>>    of this principle may lead to interoperability problems or
>>>    inconsistencies when, e.g., using data from multiple sources.
>> 
>>>> IRIs have global scope by design. Thus, two different appearances
>>>>    of an IRI should denote the same resource.  <etc.>
> 
> I find this similarly confusing than David's proposal. If IRIs have global
> scope by design then all other cases are violations. "Should" or "are
> intended to" is, IMO, too weak in this case.

Point taken. But the problem with the bald statement is that when stated this simply it is (strictly) false. What you can say is, two different appearances of the IRI should be treated as denoting the same resource, because they are referentially ambiguous in identical ways. But this is much too subtle for this place in this document. 

Part of the problem is the use of the technical word "denote" here. Why not use  the mealy-mouth word "meaning": two different appearances of an IRI have identical meanings. That is technically correct, even if it is a bit blurrier, because a 'meaning' can indeed be a way of referring ambiguously.  Actually I like this now I have thought of it. (Another option, closer to this present wording, is to use "identify" rather than "denote".)
 
> Just because that constraint is
> sometimes violated in practice doesn't mean that the spec should be written
> in such a way. All RDF 1.1 specifications are based on this fundamental
> property of IRIs. If we make this too weak here, all other specifications
> are affected by this as well. The <> IRI in the following two triples MUST
> be the same in order for the two triples to make any sense:

> 
>  <> rdf:type foaf:Person .
>  <> foaf:name "Markus".
> 
> 
>> Pat
>> 
>> PS it even works if you put it in upper case.
> 
> RFC2119 keywords don't make much sense in a non-normative section.

I was speaking tongue in cheek, but...

> That
> being said, what are the "valid reasons in particular circumstances to
> ignore" this constraint?

...good point. But perhaps this is a case of sell honest, but buyer beware?  There might be valid reasons to fear that others have ignored it, when processing RDF. Which I think is at the heart of what is worrying David. For example, Antoine's discussion about semantics of datasets notes that one reason for keeping named graphs clearly separated is because they might be mutually inconsistent, and one reason for this is that different sources may be using the same IRI in different senses. In fact, we could even argue that using an IRI to identify say, a person and also to label a graph in a dataset is itself using it in a way that violates this strict 'one denotation' condition. (But it still can be said to preserve the 'meaning', which again is flexible enough to accommodate punning of this kind, if necessary.)

My final suggestion for wording would be:

>>> IRIs have global scope by design. Thus, two different appearances
>>>    of an IRI always have the same meaning. The RDF model is based on this principle, and violations
>>>    of it may lead to interoperability problems.


Mentioning the RDF model explicitly can be read either as an emphasis on the importance of this, or as a way to saying that violations of this are just non-RDF-kosher, rather than simply impossible. 

-------

OK, no more from me on this topic, and all of this is purely a suggestion to try to get the issue resolved, nothing more. 

Pat


> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 15 December 2013 19:00:34 UTC