Re: [GRAPHS] g-box, g-snap, and g-text

To make it even more complicated, I'd add another term:

4. A "g-log" is what is logically meant by a g-snap, that is, it would 
correspond to an equivalence class of g-snaps according to the 
entailment relation.

For instance, the following g-texts---which represent different 
g-snaps---do represent the same g-log:

Ex.1 (g-text1)
:s :p _:o1 .
:s :p _:o2 .

Ex.2 (g-text2)
:s :p _:o .


Note that this notion is dependent on the semantics used (there could be 
simple-g-log, RDF-g-log, RDFS-g-log, D-g-log, OWL-DL-g-log, etc.)

Now the question is: what do we want to give a name to? If a "named 
graph" identify a g-log, then one can materialise inferences inside a 
g-box while the "named graph" (the g-log) stays the same.


Regards,
--AZ

Le 25/02/2011 04:25, Sandro Hawke a écrit :
 > I'm still having trouble following the discussion due to ambiguity of
 > terms.  But I don't want us to argue about terms at this stage.  So I'd
 > like to propose some temporary terms.  They are intentionally a little
 > quirky and not suitable for use in our final specs.  Instead, they are
 > meant to be short and unambiguous and relatively memorable.  At the end
 > of this email, I try to connect them to other people's terms.
 >
 > Here they are:
 >
 > 1.  A "g-box" is a container, like a "set" data structure in
 > programming.  It holds some RDF arcs, with their nodes. (Alternatively,
 > it holds some RDF triples.).  G-boxes can overlap, sharing some of the
 > same nodes and arcs.  Two g-boxes can happen to have the same contents
 > (right now) while being distinct g-boxes. G-boxes contents can change:
 > today a particular g-box might contain the triples { my:a my:b _:x.
 > my:a my:c _:x }, and tomorrow it might instead contain { my:a my:b _:x.
 > my:a my:c2 _:x }.
 >
 > 2.  A "g-snap" as an idealized snapshot of a g-box; it's a mathematical
 > set of RDF arcs, with their nodes.  (Alternatively, a mathematical set
 > of RDF triples.) Like g-boxes, g-snaps can overlap, sharing nodes and
 > arcs.  Unlike g-boxes, it makes no sense to talk about g-snaps
 > changing: they are defined to be exactly the collection of their
 > elements.  If a g-snap were to "change" it would simply be a different
 > g-snap.  If two g-snaps have the same nodes/arcs, they are really the
 > same g-snap.  The contents of a g-box at any point in time are a
 > g-snap.
 >
 > 3. A "g-text" is a particular sequence of characters or bytes which
 > conveys a particular g-snap in some language (eg turtle or rdf/xml). If
 > you can parse a g-text, you know what is in the g-snap it conveys
 > (except blank nodes, as discussed below).  You can tell someone exactly
 > what is in a particular g-box at some instant by sending them a
 > g-text.  (You send them the g-text which conveys the g-snap which is
 > the current state/contents of that g-box.)
 >
 > Are those terms and descriptions clear enough?  Are there edge cases
 > they are missing?
 >
 > Now, about URIs:
 >
 > * A g-box can exist without any name or persistent way of referring to
 >    it; it can exist as a data structure in a running program, or I
 >    suppose it can exists in someone's mind.  Long-lived g-boxes
 >    probably SHOULD be given a preferred single working URL, but there
 >    might be times when you do don't want to give it any, or when you
 >    want to give it several URLs.
 >
 > * You can convey a g-snap with a g-text, but I don't think you usually
 >    want to name them with URIs.  Sometimes you want to put a g-snap
 >    into a URI, but that's rare, since in many cases g-snaps are too
 >    long for most URI-handling software.  For constrained applications,
 >    though, where overrun is unlikely or okay, you can embed a g-text
 >    somewhere in an http URI (eg, as a query parameter), or maybe use
 >    "data:" URI.
 >
 > And blank nodes?   I think it works like this:
 >
 > * Two g-snaps can contain the same blank node.  A simple example of
 >    this is to take a g-snap containing at least one blank node, then
 >    construct another by adding the triple { my:a my:b my:c }.  The
 >    original g-snap and the one resulting from the union both contain
 >    the same blank nodes.
 >
 > * By a similar argument, I believe two g-boxes can also contain the
 >    same blank node, although not all software will support this.  Given
 >    a g-box A, I could construct A' to contain whatever A contains and
 >    also { my:a my:b my:c }.  This happens sometimes in real programs;
 >    I'd be curious to know which RDF APIs disallow sharing blank nodes
 >    between their graph-storage instances; my experience is they allow
 >    it when it's not a problem (eg they are both in memory right now).
 >
 > * In general, while g-texts do convey g-snaps, they do not identify
 >    the blank nodes in them.  So, in fact, if you go
 >
 >        g-snap A -->  g-text -->  g-snap A'
 >
 >    A=A' only if it does not contain blank nodes, because parsing a
 >    g-snap results in all-new blank nodes.
 >
 >    We might define new RDF syntaxes which allow for several g-texts to
 >    be grouped in such a way that blank nodes can be shared between them.
 >    This is an issue for our work item, "Either [the turtle] syntax or a
 >    related syntax should also support multiple graphs and graph stores."
 >
 > How's that sound?    Make sense?
 >
 > Okay, relating to other people's terms...
 >
 > "Tokens", as I read today's email, seem to mostly be g-texts but
 > sometimes be something that can change over time, and thus be a
 > container for a g-text, something we might call a "g-text-box".  I
 > think this later meaning conflates things in a way which will cause
 > problems, eg for understanding content-negotiation.
 >
 > "Graphs" in the RDF Semantics are g-snaps.
 >
 > "Named Graphs", as in SPARQL 1.0, are g-boxes which happen to each
 > be assigned a URI.
 >
 > "Graph Literals", as suggested by N3 (and disagreeing with Nathan,
 > sorry), are a feature of an RDF syntax that allows you to denote a
 > g-snap by a special kind of term (a "graph literal"). In n3, it looks
 > like:
 >
 >      { _:x my:says { _x: foaf:name "Sandro Hawke" } }.
 >
 > One can approximate this with every RDF syntax by using a
 > suitably-defined URI scheme or datatype, such as:
 >
 >      { _:x my:says "_:x<http://xmlns.com/foaf/0.1/name>  \"Sandro 
Hawke\""^^my:turtleCode }
 >
 > This isn't as convenient as the N3 approach, and doesn't doesn't allow
 > blank nodes to be shared (in the second example, the _:x's are not
 > connected), but it does work in existing RDF syntaxes.
 >
 > I'd better stop now.
 >
 >     -- Sandro
 >
 >
 >

Received on Monday, 28 February 2011 11:36:47 UTC