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

OK, moving this discussion to public-rdf-wg but CCing David Both for convenience.

I've updated Concepts to say

  IRIs have global scope by design. Thus, two different appearances
  of an IRI identify the same resource. RDF is based on this
  principle and violations of it might lead to inconsistencies or
  interoperability problems.

I think at the moment this is the thing most of us can live with. I took Pat's suggestion into account but avoided to talk about "meaning". Instead, I chose "identify" as that's probably the least controversial term. After all, IRIs are International Resource *Identifiers*.

Given that Pat already said that "identify" works as well and no else in the working group raised concerns about my earlier proposal I hope that David Booth can live with this as well. David, feel free to say so on public-rdf-comments :-)


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler




---------- Original Message -------------
On Monday, December 16, 2013 3:24 PM, David Wood wrote:
To: Peter Ansell
Cc: Markus Lanthaler; Pat Hayes; David Booth; public-rdf-comments
Subject: Re: ISSUE-148: RDF Concepts - IRIs do *not* always denote the same resource

Hi all,

David Booth, thank you for your comments and suggestion. The RDF WG will discuss your ideas and respond to your comment as quickly as we can manage. 

Please note that the public-rdf-comments list is not a discussion list. The RDF WG has a requirement to formally respond to comments on this list. Members of the RDG WG are requested to move any and all discussions of possible comment responses to the publicly archived public-rdf-wg list. 

Regards,
Dave
--
http://about.me/david_wood


On Dec 16, 2013, at 0:30, Peter Ansell <ansell.peter@gmail.com> wrote:
On 15 December 2013 23:30, 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. 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".


The RDF-1.1 document format specifications should not require the
world to be free of all errors to be internally consistent. If they
appear in different RDF-1.1 Datasets, RDF triples should be free to
associate separately without causing a logical "MUST" failure due to
their simple existence. The statements above are both in the default
RDF-1.1 Dataset, so they would be taken as closely linked in the
absence of any other contextual information such as a user assigning
RDF-1.1 Datasets to them locally for any purpose (such as statement
provenance or Dataset provenance).

Writing the core specification in a strict manner should also not be
necessary to allow document formats that have slightly tighter
intended audiences (for example for those of the Linked Data
persuasion) from highly recommending that people do not intentionally
reuse URIs to refer to different real world entities. If someone wants
to accept statements into their system which reuse URIs to mean
different things (particularly in the case of different RDF-1.1
Datasets) that should be up to them to manage the statements to make
their system and their exposed statements consistent from the relevant
users points of view. Forcing them to be in violation of the base
RDF-1.1 Concepts model doesn't allow for explorations into the area of
how to manage URI meaning change with reference to RDF, for instance.

A reference to RDF-1.1 Datasets that had a SHOULD requirement with
respect to URI correference within a Dataset, and another statement
that used "intended" (or other non-RFC2119 wording) for global scope
works for me. There is no reason or rationale (from my experience) to
be locally managing a single RDF-1.1 Dataset and have the same URI
mean different things in neighbour triples.

I have already been using RDF-1.1 Datasets (previously based on SPARQL
GRAPH) versioning to concurrently manage OWL Ontologies within a
single system where the meaning of a URI could legitimately be
concretely changed between graphs, particularly versions of the
ontologies that are separated by numerous intervening minor changes
that together add up to a significant change. Users simply need to
understand the system design (based on OWL VersionIRI and RDF Quads
file formats) to avoid joining particular RDF-1.1 Datasets into a
single RDF Graph (typically based on the OWL OntologyIRI. Not being
completely sure about URI coreference between RDF-1.1 Datasets is not
the only reason to avoid naively joining arbitrary RDF-1.1 Datasets
together into a single graph. Updates to an RDFS:label (for instance)
to correct a spelling mistake would pollute the resulting graph in a
naive join.

Thanks,

Peter

Received on Monday, 16 December 2013 16:57:12 UTC