Re: Draft response to Ian Davis' comment

Andy,

On 1/3/11 4:26 PM, "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote:
> The terminology "RDF knowledge" has caused comment before.  It seems the
> terminology doesn't work for some people.  I wonder if there is a better
> way to express things here.

This is the only (external) comment regarding this term and the (internal)
discussions we had came about in the context of ISSUE-49 which was about a
distinction that the term is specifically meant to clarify (i.e., the
difference between the graph and what the graph IRI identifies).  I don't
agree that the terminology doesn't work but rather in addressing comments
regarding this distinction, the wording can be clarified (and we have done
so in the past).

Specifically, Ian's comment regarding this term reflected his
misunderstanding of 1) what the graph IRI identifies - something that is
critical to making sense of the protocol model and 2) what exactly a Graph
Store is.  He says:

"I think this document would benefit from the removal of that term entirely
and the addition of a section describing how a Graph Store might aggregate
and interpret the graphs to form one or more datasets that may be accessed
with zero or more SPARQL or other services."

In the response, I attempt to address his difficulties in understanding what
a 'Graph Store' is.  Note, that this term is *not* defined the HTTP/Update
protocol specification but rather in the SPARQL Update specification.

> I think the confusion arises because:
> 
> 1/ "RDF Knowledge" is terminology unique to http-rdf-update/ but it gets
> used in sections discussing other documents where the term is not used.

It is introduced in http-rdf-update, its definition describes it as a
special kind of information resource, the term "information resource" is
used in AWWW (and nowhere else - but is used consistently there), and the
term 'resource' is used in various web-related specifications.
Specifications often introduce their own terminology and if it is done to
clarify something important to it then it is appropriate to do so.
 
> 2/ This is a protocol document and protocols are about exchanging bytes
> and manipulating state.

It is also about performing this exchange and manipulation of state in a
manner that is consistent with an architectural style (REST) which discusses
various concepts that characterize certain constraints (such as
identification) and as a protocol document that is meant to adhere to these
constraints I don't see anything wrong with elaborating in order to describe
how it does so. 

If you read the Atom Publisher protocol (which has a style I tried to follow
- to an extent), you will see that it is more than just about bits, bytes,
and interfaces.

> We all ready have:
> [[ http-rdf-update/ sec 8:
> Graph IRIs identify RDF knowledge (an information resource)
> ]]
> so why not use "information resource"?

Because the resources identified by the graph IRIs in this protocol
manipulate RDF content, RDF content is distinct from other IRs by the manner
in which they facilitate machine understandability (which is the whole point
of the SW), and there is already a priori uncertainty about what the IRI of
a named graph identifies.

> This is language used by AWWW and
> httpRange-14.

This term builds on the term introduced in these documents in the same way
that AWWW builds on 'resource' by introducing its own term 'information
resource' for a reason that is important to what the document is about
(despite the fact that it is not used elsewhere).

-- Chime


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2010).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Monday, 3 January 2011 22:14:24 UTC