Re: [Graphs] Proposal for Named Graph Semantics

On Thu, Apr 7, 2011 at 2:20 PM, Eric Prud'hommeaux <eric@w3.org> wrote:

> <snip/>
> > > > 1. Graph Identification
> > > > Let I be an IRI.  Define Graph(I) as a unary predicate such that
> Graph(I)
> > > > implies that the resource identified by I is an RDF graph.  If
> desired,
> > > this
> > > > can be described easily enough in RDF by defining a new class
> rdfs:Graph
> > > and
> > > > mapping Graph(I) to the triple I rdf:type rdfs:Graph.
> > >
> > > Perhaps you didn't intend to take a position on this, but does
> > > "resource identified by I" imply http dererencing? I can think of
> > > three interpretations of Graph:
> > >
> > >  0a. Graph(I:IRI):Boolean = ∃ G:RDFGraph ∣ RDFParse(HTTPGet(I)) == G
> > >  0b. Graph(I:IRI):Boolean = ∃ G:RDFGraph ∣ m(I) == G, m a local map
> > >  0c. Graph(I:IRI):Boolean = ∃ G:RDFGraph ∣ M(I) == G, M an RDF-wide map
> > >
> >
> > You're correct that I did not intend to take a position on HTTP
> > dereferencing.  My personal preference is against including that as part
> of
> > the spec.  It would be easy enough to specify HTTP dereferencing in 0a.
> as
> > an extension of the general mapping in 0b. by simply defining m(I) =
> > RDFParse(HTTPGet(I)).
> >
> > I don't have a strong preference between 0b. and 0c. at the moment, so
> I'll
> > defer taking a position on this.
>
> My guess is that between b and c, b is the only tenable position. c
> would imply some centralized resolution, which may as well lean on the
> protocol part of the URL.
>

Probably so.


>
>
> > > Of course these definitions presume a position on whether two graphs
> > > with the same triples == each other. Perhaps "I is an RDF graph" says
> > > to use "is" and not "==".
> > >
> >
> > Specifying graphs as g-snaps seems to imply that two graphs with the same
> > triples == each other -- as expressed in [
> > http://www.w3.org/2011/rdf-wg/wiki/GraphConceptTerminology]: "If two
> g-snaps
> > have the same nodes/arcs, they are really the same g-snap."  I'll admit
> that
> > I haven't fully thought through what the implications of this would be.
> >  Given a notion of RDF node equality and a global mapping M as in 0c. I
> > suppose you could infer I1 = I2 based on M(I1) == M(I2).
>
> That looks like the reverse function to me, saying that
>  <http://foo.example/> { <a> <b> <c> }
>  <http://bar.example/> { <a> <b> <c> }
> tells me that
>  <http://foo.example/> = <http://bar.example/>
>

Given the ongoing discussion in the other thread of issues surrounding
equality on the web, I'd like to avoid taking a position on that for the
time being.

If these are taken as graph assertions, then I explicitly said in another
part of the proposal that two graph IRIs cannot be inferred as equal,
whatever that means, based solely on graph assertions relating them to the
same RDF graph.  I think that if determining graph equality is what you are
after, the best you can hope for is to do so with respect to some GraphMap
m.


>
> In the SPARQL WG, folks said they didn't want to *have to* dereference
> HTTP URIs to serve SPARQL queries. I guess the local mapping will be
> entirely up to the tool, but that for GET'able protocols, http:, ftp:,
> file:, the user's expectation will be some graph corresponding to the
> GET of that resource.
>

I agree with those folks.  If I'm working with a quad store, I don't want to
*have to* go out to the web for a graph with an http: URI if I have some
knowledge about that graph locally.  That said, I think it's bad form to
make assertions about graphs with URIs with get-able protocols if you don't
have control of the associated naming authority, so that it could be made
dereferenceable if desired.

I wonder if the spec should give guidance as to how the g-text that is
obtained by dereferencing a graph IRI is related to (the graph identified
by) that IRI, but I don't have a proposal there.


> <snip/>
> > > I guess this argues for
> > >  1b. GraphAt(I:IRI):Boolean = G ∣ m(I) == G, m a local map
> > > where we don't try to tell one person's GA to match another's.
> > >
> >
> > I see your point here, although again I'll defer taking a position on the
> > matter.  Could we write that:
> >
> > 1b. GraphAt(I:IRI):Boolean = G ∣ ∃ m:GraphMap | m(I) == G
> >
> > Is this correct?  Does this just confuse the matter?
>
> hmm, it does seem to be a necessary parameter, like
>
>  GraphAt(I:IRI, m:GraphMap):Boolean = G | m(I) == G
>

That works for me.  Then the definition of GA would become:

3. GA(I:IRI, G:RDFGraph):Boolean = ∃ m:GraphMap ∣ GraphAt(I, m) ⊢ G


>
> (or maybe
>   m.GraphAt(I:IRI):Boolean = G | m(I) == G
>  but that seems like unwarranted notation)
>
>
> > BTW, thanks for introducing the logical notation.  This is my first stab
> at
> > writing such a document, I haven't yet located those keys on my keyboard
> :-)
>
> Maybe they're way out there beyond the '~' somewhere, but I just copy
> them from
>
> http://www.fileformat.info/info/unicode/block/mathematical_operators/utf8test.htm
>
> --
> -ericP
>

-Alex