W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [Graphs] g-text equivalence

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 21 Mar 2011 14:01:09 -0500
Cc: RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <DE61BD8E-F9A6-4816-BB2C-411059E935BA@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

On Mar 20, 2011, at 8:58 AM, Sandro Hawke wrote:

> 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.

OK, that's enough :-)

I think this illustrates for me one basic difference in thinking styles between mathematics and programming. Mathematics stipulates structures by axioms: anything that satisfies the group axioms is a group, etc.. Programming takes given structures and builds new ones out of them, and the basic stock of building blocks is centrally important. Very different ways of thinking. 

Pat
Received on Monday, 21 March 2011 19:01:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:57 UTC