Re: Indirect Graph Identification

On Friday 9. December 2011 08.03.37 Gregg Reynolds wrote:
> On Fri, Dec 9, 2011 at 6:42 AM, Kjetil Kjernsmo <kjekje@ifi.uio.no> wrote:
> > Fredag 09 desember 2011 10:51, skrev Gregg Reynolds:
> > 
> > In my opinion, what makes this non-RESTful (RESTless?) is that the
> > Request-URI is different from the (embedded) graph URI. You're
> > manipulating a different resource than you're identifying.
> 
> Hm, I don't think so.  The resource is identified by the entire URI,
> not just the embedded URI.

Of that, we agree in principle, but see my comment to Chime's comment.

> >  Now, that wouldn't be a
> > problem in practice if nobody ever saw the embedded URI. If that had
> > always been the case, I really don't care what URI you're using, but in
> > practice, I strongly suspect that's not going to be the case.
> > 
> > So, there's a graph http://example.org/foo. We both make a copy of it
> > and
> 
> That's a very strong assumption.  More (or just as) likely is that we
> will construct our graphs from different sources, using different
> techniques, etc.

Ah, that was just an example of an interaction.

> Ok, now I see the issue very clearly, and it is this:  if you allow
> embedded identifiers you inevitably end up with a clash between global
> and local semantics.  

Thank you for articulating this! It is a trait of a good discussion that we 
are able to articulate the differences clearly.


> (Or you could say that the notion of RESTful needs to be amended to
> handle the problem of embedded URIs generally.)

You know, I really don't know what these embedded URIs really are. URIs are 
completely opaque to me. :-) 

> The real problem is the notion that URIs have some kind of inherent
> stable meaning simply by virtue of being URIs.  That's the evil bit;
> it's a complete hoax.  In reality URIs have no meaning at all beyond
> the way they are actually used, which cannot be legislated.  Names and
> categories are inherently fuzzy, local, and unstable, but most
> RDF-speak is premised on the fiction that they are crisp, universal,
> and eternal.
> 
> Here's a real world example: we're working on the morphologies of
> Afro-Asiatic.  You're working on Cushitic; I'm working on Omotic.  We
> could use different URIs to name our graphs after the language
> families.  But the line between Cushitic and Omotic is not clear, so
> we decide to just use a "morphology" URI. 

Right, so I shall admit that these are lines of thought I rarely entertain. I 
have two remarks: First is that we need to make some simplifying assumptions 
now and then. I'm not a fan of KISS, usually it is just a bad excuse for not 
solving real-world-problems, but I find that semweb takes into account more 
real-world complexities that most of the alternatives, yet trying to be the 
"simplest that could possibly work". I think most (all) are aware that the 
real world is more complex than that, but we need to code the thing *now*!

Secondly, in this very limited context (graph names, i.e. a name for a bunch 
of triples), I think one would find it more useful to not think it terms of 
semantics at all, but in terms of isomorphism. If you have two graphs by the 
same name and they are different, one of them should have a different name. 
Isomorphism is hard in the general case, but small graphs can be checked with 
a few lines of Perl :-) 

As previously stated, my concern isn't with the graph store protocol seen in 
isolation (except for the RESTful stuff), my concern is with the broader SPARQL 
suite, i.e. what happens when different endpoints respond to the same queries 
with different results on the "same graph"?


> On your server, it means
> mostly Cushitic; on mine it means mostly Omotic.  Same embedded URI,
> different resources, no evil.  We can imagine that the community of
> linguists might decide as a matter of convention to use the same
> "morphology" URI for any sort of RDF morphological data (assume
> they've agreed on a schema).  Then if you want to know what meaning a
> particular researcher gives to that URI you inspect his data.  It's
> morphology stuff, but it's Chinese.  Again no evil.  On the contrary,
> this seems like the Right Way to do it to me; clients are interested
> in the data, after all, not the graph URI.  Over time, these graphs
> change as researchers add, edit, and trade data.  The "meaning" of the
> "morphology" URI (as a *type*) is set by the user community (not the
> URI itself, which need not even be human-readable) in very broad
> terms, but the meaning of any particular *token* of that URI in use at
> a particular time is local to the individual researcher's database.

The webarchy and RESTful thing to do would be to track the evolution with new 
URIs now and then. I wouldn't blame you if you couldn't be bothered though. 
:-) Now, it is a different thing what is set down in a spec as best practice.


Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Ph.D. Research Fellow, Semantic Web
Department of Informatics, University of Oslo
kjekje@ifi.uio.no

Received on Monday, 12 December 2011 15:09:47 UTC