Re: A radical proposal.

On 8/17/12 12:20 PM, Pat Hayes wrote:
> Maybe we should look at how other contexts handle this issue. After all, the contrast between a labile thing and its state is pretty universal. Take a vanilla web page, for example, consisting of some HTML. We talk of an "html web page" without getting all sweaty, but in fact there is exactly the same ambiguity here: are we referring to the, um, place where the HTML is stored and which we locate using a URL, or are we talking about he HTML in it at the present? The latter is only a state: it could change, and then poking the same URL will give you different HTML. Is it then the same web page? If Web pages are identified by URIs then it must be, surely. So web pages (in fact, all information resources identifed by URIs; I would hazard a guess) are all state-bearing entities rather than a bunch of stuff in one of their states. But, as I say, other communities seem to take this in their stride.
>
> I suspect that we feel the problem as being acute because RDF defined its own abstract syntax in terms of set theory, which does rather bring this issue of being labile into sharp focus. So I have a slightly radical suggestion, that we reconsider this idea. (After all, we are the RDF WG, so we alone have the power to do this.)
>
> 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.
>
> Under this proposal (which, to emphasise, is purely one of terminology, not actual content) we would say that an RDF/XML or an Ntriples document actually *is* an RDF graph. And when a URI resolves to such a thing, we say that it resolves to a graph; and when people talk of adding triples to a graph, we smile benignly instead of throwing a hissy fit. (Of course, this changes the graph: it is now a different graph, once one has made a change to it: but still, it is a graph.) And now the labile/fixed contrast becomes a fairly standard and easy-to-accept contrast between things that are allowed to change and things that, for some reason, are not, instead of being a contrast between two fundamentally different *kinds* of thing. And then the only people who need to talk about mathematical sets at all, would be people checking that parsers work properly.
>
> 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.
+1

>
> Comments?

I am used to the change :-)

I speak more about RDF documents and their content, these days. The 
graph oriented nature of the structured document content only bubbles up 
if I am pushed really hard.

Kingsley
>
> Pat
>
>
>
> 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
>
>
>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen