Re: A radical proposal. (was: Re: new names for g-box, g-snap)

On Aug 20, 2012, at 4:39 AM, Markus Lanthaler wrote:

> On Friday, August 17, 2012 6:21 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, 
>> [...]
>> 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 fully agree with this. Looking at it from a REST perspective basically all
> you can do is to exchange representations (the current state) of resources.
> As soon as you receive that representation it might already be outdated.
>> 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
>> 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.
> Well, to be clear, it is a representation of an RDF graph, isn't it?

Maybe we are at another terminology cliff here. The document is the thing I edit and store, and you http-poke, and you get back a REST-representation of it in the form of a byte stream. You don't actually get my document. My document is the resource. Just like HTML, where I edit an HTML document and store it on a server and call it a web page, and your HTTP GET gets a copy of it to take away as its representation. Right? 


>> 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.
> +1
>> 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.
>> Comments?
> I really like this proposal as it brings the terminology much closer to
> other Web architecture terminology... I think it would be well worth the
> effort.
> --
> Markus Lanthaler
> @markuslanthaler

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

Received on Monday, 20 August 2012 14:39:55 UTC