Re: A radical proposal.

On 08/17/2012 09:20 AM, Pat Hayes wrote:
> Perhaps we should not define a graph to BE a set, but rather define it to be any RDF document or structure which *parses* to a set. So we keep the idea of the set-based abstract syntax, but we morph the terminology to be more in line with the way most of the world actually speaks and thinks.
+1 This sits well with me.  People understand that a name can be for a 
value or for a variable, and instance and a class, so we need not 
belabor the issue too much.  We also don't have trouble distinguishing 
between class and object.  A URI might represent where you got a graph, 
what you got from that URI, what you're storing locally as a snapshot of 
it.  These all seem like valid semantics for the URI.

>
> It would take us a while to get used to this change, but I think that once we had gotten used to it, we and everyone else would feel a great sense of relief. And Richard and myself would have to rewrite parts of the Concepts and Semantics text, but again I dont think it would be very difficult.
I'm already used to it.  It seems to imply that we don't need the line 
between graph/space and between dataset/graph store (in David's 
proposal), and that 'naming' although agnostic on mutability, only 
appears once in the diagram.    Moreover, if one really must uniquely 
identify a specific set of triples, for good, we can look to 
document-based mechanisms (signing bytes).

Charles



On Aug 17, 2012, at 8:31 AM, Sandro Hawke wrote:

>> On 08/17/2012 09:09 AM, Steve Harris wrote:
>>> It's probably all academic, I'd be willing to bet that whatever this group decides, everyone outside it will continue to refer to them as "Graph URIs" - and please don't bother telling me all the ways in which that's incorrect:)
>> I think you're right, and it makes me miserable.    It seems unlikely we'll come up with any terms that actually resonate with people and are adopted.
>>
>> My favorite idea here is to call g-snaps "graph states".    People deeply understand that a "state" is an abstract mathematical concept, so when you say you're changing a graph state, they know you really mean you're changing the graph from one state to another.
>>
>> Then I'm not sure if a g-box gets called a "graph container" or just a "graph".   Calling it a "graph container" is nice, because it makes it more clear that "graph" is ambiguous.   But then it seems like we ought to call g-snap "graph container state".
>>
>> (But I know, I know, this would betray all the people who've actually been following the guidance of the 2004 spec.   It would have lots of its own problems.)
>>
>>      -- 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
>
>
>
>
>
>


-- 
Charles Greer
Senior Engineer
MarkLogic Corporation
charles.greer@marklogic.com
Phone: +1 707 408 3277
www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

Received on Friday, 17 August 2012 16:58:40 UTC