Re: [GRAPH] graph deadlock?

On Dec 21, 2011, at 1:34 PM, Lee Feigenbaum wrote:

> On 12/21/2011 12:52 PM, Kingsley Idehen wrote:
>> On 12/21/11 12:23 PM, Andy Seaborne wrote:
>>> 
>>> If the 4th slot IRI (label) is actually denoting the graph container,
>>> and the triples have the IRI in the object slot, that IRI must denote
>>> the graph container.
> 
>> Yes. Which goes back to comments made by Lee and I about how our
>> respective products work. Basically, make statements about the named
>> graph using its IRI if that sort of granularity is required for a given
>> solution.
> 
> Yup, just to agree with Kingsley. I appreciate the efforts of everyone who is attempting to solve this problem by talking about named graphs as labelled graphs or pairs of URI + graph, but we do more than that: we DO use the URI to denote the graph in some contexts and something else (a person, a protein, whatever) in other contexts.

Exactly. This is the heart of the matter. 

> We know this isn't semantically kosher, and we can imagine situations in which it could actually lead to confusion: but in practice, it's been a very useful way to build applications and has never led to any confusion:

Right. And I would like to clarify what it is that makes this work in practice, and build it into the RDF model. 

> the context in which the URI is used (as Kingsley says, this often means the predicates that it's used with) makes it quite clear whether we're talking about a graph or about a jiggerwidget.


Just as it does in OWL 2 punning. There seems to be a very useful piece of machinery in operation here: we can allow IRI overloading provided that the 'context' always clearly disambiguates our puns. I think it would be extremely useful to try to tease out this idea and get it made clear. 

> Now, I'm not asking that the rest of the world do this; I'm not asking that RDF semantics be changed to make this use kosher.

But I am. That is exactly what I would like to do. Moreover I think I know how to do it, in broad terms. 

> I'm OK with it not being valid and I'll work to identify any situations that will break because it's not valid. I'm just sharing what our experiences have been in in practice.

Great. Here we have a clear case where actual practice goes outside the 2004 specs in a way that clearly works in the real world. So lets try to codify what it is that makes it work, and build that into the standard. 

Pat

> 
> Lee
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 23 December 2011 15:41:37 UTC