Re: New draft of section 5.5

David Booth wrote:
> 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

Things are getting confused here, the use case doesn't capture Ed's 
view, and it's precisely the inverse of what David is discussing.

Chimera is when the same graph uses a single name to refer to two 
different things, note Ed's terminology "and if I *also*"

He's saying that all these statements would be in one graph:

<http://en.wikipedia.org/wiki/William_Shakespeare> a foaf:Person ;
   foaf:name "William Shakespeare" ;
   dcterms:modified "2010-06-28T17:02:41-04:00"^^xsd:dateTime ;
   cc:license <http://creativecommons.org/licenses/by-sa/3.0/> .

Not in two graphs, or made by two different people.

Thus David, sorry to say, but what you propose in your own section 5.5 
doesn't cover the case Ed is talking about (well it does, btu it doesn't 
say what you want, because the conclusions you come to would need to be 
applied to the above graph to either create two graphs or remove half 
the statements, *prior* to publishing, which == not asserting the above 
graph ;)

Best,

Nathan


> 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.
> 
> 
>

Received on Tuesday, 5 April 2011 16:07:05 UTC