Re: Proposing new terms for g-snap and g-text

On Tue, 2011-07-12 at 17:26 -0500, Pat Hayes wrote:
> On Jul 12, 2011, at 3:09 PM, Andy Seaborne wrote:
> 
> > ....
> > Sandro defined g-text as:
> > 
> > [[
> > 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).
> > ]]
> > which works for RDFa etc reading it as not ruling other bytes about something else as well.
> > 
> > Anything where there is one graph so not TriG.
> > 
> > In fact, if we don't have something for g-text, I think it might default to "[RDF] document". "serialization" is OK but it is bulky.
> > 
> > “Representation of a resource [in RDF syntax XYZ]” feels like it begs the question again even if technically correct.  I have also seen "a graph represents ..." using representation at a different level.
> 
> Oh yes, graphs certainly represent. Not AWWW-represent, of course. I think 'serialization' or 'document' is better for the g-text idea.
> 
> A question for Sandro: if I prod a g-box and it sends me a g-text, and then I store that g-text in a file, have I now created a(nother) g-box?

Yes.   A file which contains a g-text is a kind of g-box.

>  What if I put the file into a Web server and give it a URI?

Then it's a web-accessible g-box.

>  More generally, what does it take to transform a mere g-text into a fully fledged g-box?

I can think of it two ways: either putting the g-text into some
container (like a computer file, a dbms, as a printout in a binder,
etc); or address by location, like the data on track 0 of a particular
hard drive, or the stack of papers on the left front corner of my desk,
or on the whiteboard in my office.   I guess the difference between
these two is that a box is a location with another level of indirection;
I can conceptually move or rename it.

This clearly touches the Web notion of "Resource" but it's different in
two ways: (1) we want a concept that works with or without the Web, and
(2) we only need it work for storing RDF Graphs.  TAG discussions are
much hampered in ways we're not, because (re 1) it's not clear where the
boundaries of the Web are, and (re 2) it's not clear, outside of RDF,
what kinds of information and representation they are dealing with.

So, I think we have a somewhat simpler problem than the tag does; it
seems like one much better addressed as a normal Computer Science and/or
Software Engineering issue than as a Web Architecture one.  I'd hate for
us to get stopped by the TAG's difficulties.

     -- Sandro

> 
> Pat
> 
> > 
> >  Andy
> > 
> > 
> 
> ------------------------------------------------------------
> 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 Wednesday, 13 July 2011 14:39:02 UTC