Re: [Graphs] g-text equivalence

On Sat, 2011-03-19 at 20:29 -0500, Pat Hayes wrote:
> On Mar 19, 2011, at 7:16 PM, Sandro Hawke wrote:
> 
> > On Sat, 2011-03-19 at 19:02 -0500, Pat Hayes wrote:
> >> On Mar 18, 2011, at 3:56 PM, Sandro Hawke wrote:
> >> 
> >>> On Fri, 2011-03-18 at 19:22 +0000, Andy Seaborne wrote:
> >>>> 
> >>>> Is g-snap->g-text is just a function of the content type?
> >>> 
> >>> Well, probably, for our purposes, I think so.  
> >>> 
> >>> There's a trivial case where it's not: the  arbitrary non-semantic
> >>> variability in serialization, eg whitespace.  So, some notion of
> >>> equivalence class of g-texts may be important.
> >> 
> >> Can't we simply *define* g-texts to be equivalent under such trivial variations? It is our notion, after all.
> > 
> > I'm not quite sure what you mean.  I think it's important the g-text be
> > a subclass of character or byte strings, so *equality* is string
> > equality.
> 
> Well, that kills my suggestion right there. So let me push back on this point. Why do you think this is important? Why should a g-text not have its own g-style notion of equality? Why should it be a subclass of byte strings? 

Strings are very real to me (as for most programmers, I suspect), and
having g-texts be strings is very comforting.  I could probably get used
to some other abstraction (as I have with RDF graphs), but there would
still be strings being transmitted down the wire, which I would
sometimes need to pay attention to, so I'd still need a notion of
strings-representing-graphs in addition to whatever might serve this
equivalence/equality purpose.  I suppose we could give that abstraction
a name and see if it's useful -- maybe a g-coding?  But I can't actually
see how I would use that, and where it would sit between graphs and
strings.

(Okay, of course strings don't really exist, and I'm using a wireless
connection, but I think that just proves my point, that strings are an
abstraction I'm terribly familiar with.  They feel real, and introducing
a different-but-similar abstraction would confuse me.   It feels a bit
like you're proposing we defines something like "Cat" (in the normal
sense of the word, a domestic feline), but such that all cats born on
the same day are the same cat.    That's too weird for my brain.)

> >  For equivalence, yes, it seems like there's a simple and
> > obvious meaning of equivalence, but I don't know how to formalize it,
> 
> You did later in the message :-)

Indeed.  :-)    Why is it this group does most of its interesting email
during non-work hours, even when you account for the time zones of the
members?   (this is sequitur because during work hours I would have put
more time into re-writing the email.)

    -- Sandro

> I guess my overall question is, why do we need to distinguish identity from equivalence? Maybe this question is a residue from when I used to think like a mathematician, but I'd be interested in your answer.
> 
> Pat
> 
> > and I maybe it's not that quite that simple, for example:
> > 
> > g-text t1: '_:x <http://www.w3.org/2000/01/rdf-schema#comment> "Hello"'
> > g-text t2: '_:x  <http://www.w3.org/2000/01/rdf-schema#comment> "Hello"'
> > g-text t3: '_:y <http://www.w3.org/2000/01/rdf-schema#comment> "Hello"'
> > 
> > I think all of the are equivalent, but the equivalence of t1 and t2
> > (where the difference is just whitespace), seems somewhat different from
> > that between either of them and t3 (where the difference is in blank
> > node labeling).
> > 
> > Should we just define a single standard "equivalence" of g-texts, or do
> > we need to allow room for there being several different kinds?
> 
> Why would anyone need different kinds?
> 
> > 
> > Maybe the simple notion is "semantic equivalence" of g-texts, which I
> > might define as:   T1 and T2 are semantically equivalent iff the RDF
> > graphs produced by correct parsing of either of them are
> > indistinguishable.   
> > 
> >   -- Sandro
> > 
> >> Pat
> >> 
> >>> 
> >>> There's a related problem I don't know if we can or should address,
> >>> which is how to deal with websites which use cookies or other
> >>> information (IP address, browser sniffing, etc) to customize content.
> >>> 
> >>> Does AWWW deal with these at all?   Not that I recall.
> >>> 
> >>> For an RDF example, I could make it so http://hawke.org/ip returns
> >>> something like 
> >>> 
> >>>       { <> eg;currentClientIP "128.113.1.1" }
> >>> 
> >>> ... but returning your actual IP address.  Given the right cloudhosting
> >>> infrastructure, I could meaningfully, and perhaps usefully, return two
> >>> different non-equivalent g-texts (ie g-texts for different g-snaps), at
> >>> the exactly same moment in time.
> >>> 
> >>> So, I think the model of web addresses identifying g-box which contains
> >>> one g-snap at any point in time is as good as REST, and probably good
> >>> enough, but still not perfect.
> >>> 
> >>>   -- Sandro
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> ------------------------------------------------------------
> >> 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
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> > 
> > 
> 
> ------------------------------------------------------------
> 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 Sunday, 20 March 2011 13:58:21 UTC