Re: "RDF Knowledge" (Uniform HTTP Protocol for Managing RDF Graphs)

On Mon, Feb 7, 2011 at 12:07 PM, Chimezie Ogbuji <chimezie@gmail.com> wrote:

Hi again,

Thanks for the response.  Aside from the issue of whether the Uniform HTTP
protocol is needed,  I can now see exactly why we're having trouble
understanding each other.  We have two fundamental points of disagreement,
one regarding the meaning of the term "RDF Graph" which you take to refer to
'abstract syntax', and which I take to refer to a graph (mathematical
object), and one regarding the denotation of a graph URI, which you take to
be a concept distinct from the (its?) graph, and I take to be a graph.
 Comments below.

-Gregg

 ...

> >   I can't tell what you're talking about.  If you mean that HTTP is not
> > sufficient to support a RESTful architecture for RDF resource services,
> then
> > I respectfully but very strongly disagree.
>
> I'm not sure how you concluded that from what I was saying, but let me
> help clarify: that is *not* what I'm saying.  Again, I'm saying that
> there is very little precedence that a developer who wants to expose
> an RDF dataset over HTTP (for Create Read Update Delete operations)
> can follow to do so.  That is what standards are for: to standardize
> where there is a need and little consensus.
>

Ok, so we agree that HTTP is sufficient to support a RESTful architecture
for RDF resource services.  Your claim seems to be that in spite of this
fact, there is a need to promulgate a standard explaining how to do so (or
something like that; I'm not sure what you want to standardize.)  You say
there is a need; I say there is no such need.  In my opinion it is encumbent
upon you to demonstrate the need.  Who is calling for this standard?  Why?
 What specific problem do they want to solve?  (Note:  "there is no
precedent to follow" is speculative and not a specific problem.)


>
> > But the more fundamental problem is that this kind of language - "manage
> rdf
> > graphs", "managing a graph store" (section 3) - is incompatible with
> REST.
> >  REST is about resources, not stores, not rdf, not graphs.
>
> REST is about web resources, their representations, and provides a
> conceptual architecture of these components and how the HTTP protocol
> 'manages' them.  I'm using the word manage in the normal english
> sense, FYI.
>

I respectfully disagree that REST is about "how the HTTP protocol 'manages'"
these things.  Resource/representation management is only one way REST can
be *used*; it is outside the scope of REST proper.


> This protocol discusses how the resources that RDF documents are
> serializations of can be managed over HTTP (which is why there is a
> distinction in the terminology between the graphs and the resources -
> per your point later below).  I don't see where there is any
> incompatibility
>

I'm not sure what you are referring to respecting incompatibility, but I
would say that if the universe of discourse is limited to REST, then the
*only* actions under discussion are defined by the HTTP methods, which
clearly excludes "management" (in the normal English sense).  I.e.
addressing management actions is incompatible with a purely RESTful
approach.

To be clear:  the W3C should not be in the business of standardizing the way
implementers choose to manage their resources.  The building blocks are
provided by HTTP; everything else is for the implementer to decide.  Let's
not forget that premature or excessive standardization can stifle
innovation.


>
> > The document in
> > various places makes unmerited assumptions about resources; for example,
> > section 4: "In this way, an HTTP request can route operations towards a
> > named graph in an [sic] Graph Store via its Graph IRI."
>
> This is a typographical error that was identified in a recent review
> and fixed to say: "The HTTP operations defined here use URIs to route
> native HTTP operations to an implementation of this protocol which
> responds by making appropriate modifications to the underlying Graph
> Store"
>
> > In my view this
> > language is deeply unRESTful.  Requests do not route; IRIs denote
> resources,
> > not Graph Stores; there is no such thing as a "Graph IRI"; the kind of
> > server process standing behind an IRI is beyond the scope of the RESTful
> > interface.  The quoted sentence seems to be saying nothing more than that
> > IRIs denote resources, and it is up the the server to decide what exactly
> > that means.
>
> You are reading too much into a typo.  Hopefully, the modification
> makes that clear
>

I don't know what gave you the idea that my comment was about copyediting.
 Please read it again, for content.


>
> > Look at it from another perspective:  why do we not standardize a RESTful
> > protocol for managing JPEGs?  Or Word docs?  Or any other kind of data?
>
> See my Atom Pub analogy above.  By that line of reasoning, the Atom
> Publication protocol (or any any protocol that is conceived as an
> HTTP-bound interface to managing certain kind of content) is
> unnecessary.
>

I'm not familiar with Atom, nor should I need to be; I suspect the Atom
protocol is either unnecessary or application-specific, which RDF is not..
 Are you arguing that we should standardize a protocol for every type of
content?  I don't think so; but then, you did not answer the question; all
you did is cite another protocol.


>
> > A protocol for "managing graphs" is no different in principle than one
> for
> > "managing JPEG images".  We don't standardize the latter; why do the
> former?
>
> Because the standards underlying the semantic web primarily support
> read, but not a write interfaces, there is a need for interfaces for
> updating RDF content (hence the SPARQL Update language team
> submission), and there is no consensus or standardization on how this
> is done in general.  In particular,there is no precedent on how this
> is done in the context of the architectural style of hypermedia
> applications (REST).  JPEG images are mostly involved in read
> operations, they are simple (stand alone) digital content that are not
> involved in a larger data structure (such as Atom entries and Atom
> collections on the one hand and RDF graphs and RDF datasets on the
> other).  So, that analogy doesn't make sense to me.
>

Are we talking about the same web?  Flickr?  Facebook?  Youtube?  Etc. Etc.
 The web is chockful of sites that already do exactly what you claim is
unprecedented.  Including "managing" RDF using PUT, DELETE, etc.  I do it
regularly.


>
> >  Or: it makes no difference if there is a massive distributed database
> farm
> > or a simple filesystem behind an IRI, and it doesn't matter what format
> is
> > used to store the data behind the IRI; from the client perspective, it's
> > just a resource, for which the server dispenses a token
> > (serialization/representation).  At the very least, none of these
> standards
> > docs should make reference to "Graph store", data store, data base, etc.
> >  They should stick religiously to "resource" or "graph resource".
>
> I don't follow the need to religiously (as you say) avoid terms
> outside of the architecture of the web.


"Outside of the architecture of the web" is not the point.  The point is the
writing should be fastidiously correct, coherent, and consistent with
established usage.


>  The reference to a graph

store is necessary because RDF graphs (which comprise the content that
> such an interface is meant to manage) are part of an RDF dataset, but
> RDF datasets are not mutable.  There was a previous thread in this
> list on this topic (I don't have the link off hand) that discussed
> this.
>
> > Speaking only for myself, obviously, I've gone over the draft pretty
> > carefully and I see nothing there that is not a restatement of existing
> > standards.
>
> Okay.  I've asked for you to elaborate on this and I have yet to hear
> (speaking for just myself) a response that is more specific beyond
> this general assessment and thus constructive as input into a
> conversation to consider the issues and make modifications (if the WG
> thinks such modifications are necessary).
>

Ok, tell me what counts as elaboration.  I believe I've been pretty clear
that I don't see any need for standardizing RESTful RDF stuff.  Obviously I
cannot prove a negative, so I think it is up to you to demonstrate there is
a need.  Regarding specific bits of language, I believe I've already given
numerous clear and specific examples.  I don't know how to be more clear and
specific.


> >  Can you provide a specific example illustrating failure of HTTP
> (including
> > standardized extensions) to support a RESTful API for RDF resources?  I
> > can't think of one.
>
> I think this question follows from your reading too much into the typo
> above.  There is nothing in *this* protocol that is saying HTTP cannot
> support a RESTful API for RDF resources.  In fact, it is saying the
> opposite and attempting to standardize such an interface.
>

I think I've covered my objections to this already, so instead here's a
simple question.  If, as you believe, there is a need for standardization
here, then lack of such standardization must be causing some problems.  What
specifically are those problems?  This is not  a rhetorical question; * *I
cannot think of any such problems, but the web is a big place.  If you can
demonstrate specific and practical negative consequences of lack of
standardization then I will whole-heartedly endorse the effort.  (Even if
you can't you'll be relieved to know that I think I've said enough about
it.)


> >> This protocol is meant to address this by defining a protocol that uses
> the
> >> constraints of REST to define how RDF graphs can be manipulated
> >> directly and natively in HTTP.
> >
> > I strongly oppose this.  HTTP is already defined; so is REST.  Anybody
> who
> > wants to implement a REST architecture over HTTP to serve up RDF
> resources
> > just has to do a little research to figure out how.
>
> Standards are created to bring order to the various ways that
> something (for which there is substantial need) can be done.  It is
> precisely because some research would need to be done and (in my
> opinion) even having done this research there are multiple HTTP
> interfaces that would result that you would want to standardize that
> situation.
>

What is the problem with multiple HTTP interfaces?


>
> > Furthermore, whether
> > somebody wants to use a RESTful architecture or RPC or any other design
> to
> > implement RDF services is none of W3C's business.
> > Architectural patterns
> > are not an appropriate area for standardization in my opinion.  Would
> > anybody suggest publishing an MVC "standard"?
>
> This is not advocating either, so I don't understand your point.
>

Presumably one promulgates a standard in hopes that it will be used.

>
> > ..snip..
> >> The term 'RDF Graph content' (although it doesn't use the word
> >> 'knowledge' which many found not helpful) does distinguish between the
> >> syntax (or structure) of an RDF graph and its meaning (or content).
> >
> > Huh?  Not to my eye it doesn't.  First off, this sentence suggests an
> > equivalence between syntax and structure.
>
> Actually, it is trying to distinguish between
>
> RDF document -> 'syntax'
> RDF graph ->  'abstract syntax'
> RDF graph content -> thing denoted by graph URI
>

Well no wonder we're talking past each other!  In my view such usage is just
wrong.  I'll save the details for another post, but the summary is that the
distinction between abstract and concrete syntax is irrelevant in
denotational semantics.  Syntax, whether abstract or concrete, is language,
not meaning.  Translate your mapping here into basic mathematical notation:

symbol '3' => 'syntax'  (i.e. concrete syntax)
integer 3  =>  abstract syntax
integer 3 content => thing denoted by some 3 URI

That's not how denotational semantics works.

> Syntax may have structure, and
> > graphs may have structure, but these are clearly different things.
> >  Sentences and other expressions have syntax; graphs do not.  If this
> isn't
> > clear, consider sets.  An expression like {1, 2, 3} has syntax; the set
> it
> > denotes has structure, but not syntax.
>
> I'm sorry, but I don't follow your analogy, your use of the terms
> 'syntax' and 'structure', or your reasoning behind how you have come
> to assume the protocol is suggesting an equivalence between them.
>

I was referring to your words (above):  "the syntax (or structure) of an RDF
graph".  I see now why you say this, since you take "RDF graph" to mean
abstract syntax.  But such an interpretation is non-standard.  I take "RDF
graph" to refer to ... wait for it ... the RDF graph!  Just like I take "the
integer 3" to refer to the third integer.


> > A graph is a graph; it has no "content".
>
> Let me try yet again with another analogy.  Consider my FOAF graph.
>

Foul!  Begging the question!  You can't use RDF to provide semantics for
RDF.


> There is the abstract syntax that we draw with the nodes and arcs.
>

You cannot draw abstract syntax.  By definition.  Nodes and arcs syntax is
concrete syntax.


> Then there is the syntax of an RDF document which serializes that
> graph toplogy.  Then there is the concept of my social network that
> the graph 'denotes'.  The latter is the 'content'.
>

I note in passing that your account of how all this works jettisons model
theory.  All you have is concrete syntax, abstract syntax, and a concept
(which is not a mathematical object).   You have eliminated the model
theoretic interpretation, which maps syntax to mathematical object.


>
> > Similarly, a set is a set; it has no
> > "content".
>
> foaf:Person a owl:Class
>

Begging the question.

>
> foaf:Person is (loosely) a set of things (the set of people) and the
> set (as used in that vocabulary) denotes the concept of Homo Sapien.
> This is basic RDF / OWL MT and underlies how RDF is meant to be a
> machine understandable knowledge representation.  It seems we have
> some disconnect between us on a very rudimentary level.
>

Indeed we do.  I would say disagreement rather than disconnect; based on
your comments I think I understand what you're saying.  I just think it's
wrong.


> > This is not the same as saying it has no members.  The point is
> > that you cannot postulate a third entity "content" that is distinct from
> the
> > set and its members.  Well, you can, but it would come as a surprise to
> > mathematics.
>
> Not really.  In mathematical logic there are constants that denote
> 'things', sets of constants that denote categories of 'things'.


Mathemtatics != Mathematical logic.  And I thought the logical constants
were AND, OR, NOT, and so forth.   They do not denote.   Plus, "Constants
that denote categories of 'things'" in mathematical logic is a new one on
me.  Never heard of it.  Can you provide a reference to literature that
explains this?


>  RDF
> is similar, except the constants are the URIs and the things denoted
> are the 'resources'.   The term 'RDF graph content' is using the same
> rudimentary, mathematical logic mechanism but at the level of a graph
>

Well, I'm no expert, but I'm pretty comfortable with at least the basic
ideas and language of mathematical logic and I've never come across anything
recognizable to me as what you refer to as "content".  Can you provide a
reference to the literature that would clarify this?

Aside from that, there is a pretty obvious inconsistency in your language.
 Here you claim that "content" is a bit of ordinary mathematical logic;
below (and above) you claim that the content is a concept like "my social
network", which is obviously not within the scope of mathematical logic.  It
can't be both.
 ...

>
> > Maybe you can clarify what is intended by distinguishing between "graph"
> and
> > "graph content".
>
> ...

> [[[
> [...] we are not directly identifying an RDF graph [with
> http://example.com/rdf-graphs/employees] but rather the RDF graph
> content that is represented by an RDF document, which serializes that
> graph. Intuitively, the set of interpetations that satisfy [RDF-MT]
> the RDF graph serialized by the RDF document can be thought of as this
> RDF graph content.
> ]]
>

As I mentioned in a previous message, I indeed believe this kind of language
is not only hideous but logically incoherent.  Although now that you have
explained what you understand by the terms (RDF graph, etc.) I see how you
are interpreting it.


> If the URL http://copia.ogbuji.net/foaf/me.rdf is the URL of a graph
> describing my social network then that URL does not denote the RDF
> graph but the concept of my social network.
>

In other words, the URL identifies a graph, but denotes a social network.  I
could not disagree more; to me this is logically incoherent, although I
reckon lots of people would agree with you.  It's like saying that, if Joe
is 27 years old, then the symbol '27' denotes not an integer but the concept
of the age of Joe.  I daresay nobody would assent to this interpretation of
the term "denotation".


>
> >> This follows from the model theory of RDF, which provides a way for
> >> RDF graphs to be interpreted and there is an understood (as with other
> >
> > Not quite.  It provides a way for expressions in an RDF language to be
> > interpreted.  RDF graphs are the things that are denoted.
>
> I don't understand what you are trying to say here.
>

I hope my comments above make this clear.  You take "RDF graph" to refer to
'abstract syntax', in which case it makes sense to say that MT assigns an
interpretation to the RDF graph (although, since you map the syntax to a
concept, you've in fact deviated from MT).  But in my view this usage is
incorrect, since it deviates from standard usage, which takes "Foo graph" to
refer to a graph (of type Foo), and in which the distinction between
abstract and concrete syntax is not relevant.  In which case it would be
wrong to say that MT assigns an interpretation the the RDF graph.

>
> > An IRI identifies a resource; if that resource happens
> > to be a graph, then it identifies the graph.
>
> This seems like circular logic to me.
>

It's not logic; there is no inference here.  More like pre-logic.  Names
name the things that they name.


> >   "Graph" here means
> > mathematical object; it most definitely does not mean graph expression or
> > syntax or representation or serialization of a resource.
>
> I cant make sense  of why you think this distinction between what the
> graph URI identifies and the graph it is paired with in the RDF
> dataset is (as you put it) 'vague' and 'incoherent'.


I hope my comments here make this more clear.  If not, I suggest you try
forgetting RDF for a moment and think in terms of ordinary standard
mathematical notation, where there is clearly no notion of a distinction
between what a name names, and "content".


>  If you think
> this (fundamental) understanding of the relationship between a graph,
> its URI, and what the URI identifies is problematic then I suggest you
> separate  this substantive complaint / issue out from your comment on
> this particular draft (which is not the source of the distinction).
>

True.  It looks like I have a very basic disagreement with the view of RDF
you've described, which I imagine is shared by a lot of people.  However,
whether this particular draft is the source of the distinction between graph
and graph content isn't particularly relevant in my view; if you're going to
use those terms, you should provide an adequate definition.  The fact that
it is possible to offer radically different definitions seems like a pretty
good  reason to question whether the document should be published as a
standard.

Sincerely,

Gregg