Re: New draft of section 5.5

This may get confusing having parallel versions of section 5.5 going
back and forth, but maybe it will help us converge.

Anyway, here are comments on your latest version of sec 5.5
http://www.w3.org/2001/tag/awwsw/issue57/latest/#chimera


1. This paragraph is vague, but given that it is just the introduction
that is setting the stage, it may be okay:
[[
Currently we use a dereferenceable hashless URI 'http://example/p16' to
refer to the information resource at that URI, IR('http://example/p16')
(see 7.3 Using a URI to refer to the information resource accessible via
that URI). To use an http: scheme 'hashless URI' to refer to anything
else, one uses a 303 redirect. To address performance and deployment
difficulties with 303 redirects, it has been suggested that the same URI
be used for two purposes: to refer to the information resource at that
URI, and to refer to some entity given by a definition of the URI that
is carried by (a version of) the information resource itself.
]]
However, I am concerned that it is a bit misleading, because practically
any time a URI is used in two different graphs it may be referring to
different things -- sometimes very different, sometimes only slightly
different.


2. This paragraph contains some critical implicit assumptions and
non-observable claims:
[[
Carol encounters both bits of RDF (or either) and needs to make sense of
them. Suppose she is aware that 'http://example/p16' might be used in
both ways - in metadata, with the intent that the metadata is about
IR('http://example/p16'), and according to a definition found in
IR('http://example/p16'). For each use of 'http://example/p16' she (or
her software) needs to determine which sense is supposed to apply.
]]

To break it down:
[[
Carol encounters both bits of RDF (or either) 
]]
This is vague.  We need to be specific about exactly what RDF assertions
she is using.

[[
and needs to make sense of them. 
]]
No, she needs her application to produce the correct *output*.  If we
cannot translate Carol's problem into something that demonstrates an
*observable* difference, then we're wasting our own and everybody else's
time.

[[
Suppose she is aware that 'http://example/p16' might be used in both
ways - in metadata, with the intent that the metadata is about
IR('http://example/p16'), and according to a definition found in
IR('http://example/p16'). 
]]
This is vague but (I think) innocuous, because it is merely talking
about Carol's mental strategy -- not what her app is actually doing.

[[
For each use of 'http://example/p16' she (or her software) needs to
determine which sense is supposed to apply.
]]
This needs to be much more specific: state exactly what output should be
produced for what input.  It could be written in pseudo-code, in n3
rules, or in something else, but it needs to be concrete and specific,
for two reasons: (a) to enable us to objectively distinguish between
correct output and incorrect output; and (b) to ensure that there are no
"miracle" steps in the process.


3. 
[[
What the agents using this protocol need - both those composing
statements and those deciphering them - 
]]
We should stick specifically with Carol's problem rather than trying to
generalize this to other problems that have not been clearly identified
and may be different than Carol's problem.


4.
[[
is a general rule for classifying each occurrence of a URI u as
referring either to the information resource IR(u) or to what the
content at IR(u) describes.
]]
This is a bit misleading because it suggests that it is meaningful to
say that a URI in isolation refers to something in particular, but it
doesn't.  I think it would be more accurate to frame this as a problem
of partitioning the graph into two graphs g1 and g2, such that each
graph is consistent and Carol's app produces the correct output on them.

5. The remainder of sec 5.5 is essentially explaining why the strategy
of partitioning the graph based on classifying the properties is
infeasible in general.  Another strategy for solving Carol's problem
would be identity splitting, as I described in my draft sec 5.5.  If we
know of other strategies we should list them also.



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 5 April 2011 14:25:28 UTC