Re: comments on section 12 (and a little more)

Meant for the list

-------- Original Message --------
Subject: Re: comments on section 12 (and a little more)
Date: Mon, 19 Mar 2007 09:51:07 -0500
From: Pat Hayes <phayes@ihmc.us>
To: andy.seaborne@hp.com
References: <p0623090dc22353b62869@[192.168.1.2]> <45FE943E.3000802@hp.com>

 >First pass - editorial.
 >
 >Only specific comments mentioned here because it
 >seems that many of the changes have already been
 >done.

Ouch. Was I looking at the wrong version??

 >
 >Pat Hayes wrote:
 >>Overall comment (important).
 >>
 >>There is a disconnect between the ideas of
 >>dataset and graph, which I think needs to be
 >>fixed. Section 8 discusses datasets in great
 >>detail with many examples, but it nowhere
 >>actually defines explicitly which RDF graph is
 >>determined to be the one that BGPs are required
 >>to match against. Section 12.3.2 defines
 >>matching for BGPs, but speaks of matching to a
 >>dataset (mia culpa). Section 12.5 finally
 >>introduces and uses the terminology "active
 >>graph", but it does not formally define this
 >>notion or say how it is computed. (See detailed
 >>comments of 12.5 below) In any case, it is far
 >>too late in the document for this idea to be
 >>defined.
 >>
 >>"Active graph" is a basic concept which should
 >>be defined in section 8, which should give
 >>clear criteria for how to determine it given a
 >>query and a dataset. Then 12.3.2 should use
 >>this term when defining BGP matching, and the
 >>references in 12.3.2 and 12.5 should have
 >>internal links to the definition in section 8.
 >>
 >>--------
 >>Comments on Section 12
 >>
 >>"query as as string" -> "query as a string"
 >>"abstract query comprises operators" -> "abstract query comprising operators"
 >
 >Already done in the version I'm looking at.
 >
 >>"this can then be evaluated"  Should we only
 >>say 'can' here? Suggest "this is then
 >>evaluated".
 >>
 >>"This section defines the correct behavior for
 >>evaluation of graph patterns and solution
 >>modifiers, given a query string and an RDF
 >>dataset.  "
 >
 >"""
 >This section defines the correct behavior for
 >evaluation of graph patterns and solution
 >modifiers, given a query string and an RDF
 >dataset. It does not imply a SPARQL
 >implementation must use the process defined here.
 >"""
 >
 >>
 >>But you just said we would cover the process
 >>starting with the abstract syntax, not the
 >>string. Correct one of these statements.
 >>
 >>This whole process seems awfully complicated
 >>and unmotivated. Can you give some guidelines
 >>on what the differences are between abstract
 >>syntax and abstract query and SPARQL algebra
 >>(?) . This whole topic of converting form one
 >>form to another isn't mentioned again until
 >>12.2, and none of the intervening definitions
 >>in 12.1 seem to be relevant to it.
 >
 >12.1 puts all the basic definitions in one place.
 >
 >How about:
 >1/ Move BGP defn to 12.1
 >2/ Remove 12.1.5 (Graph patterns) as they are
 >not needed (the definitions go via the algebra
 >operations),
 >3/ Remove current "SPARQL Query" (more emphasis
 >on the query string removes the need for this)
 >4/ "SPARQL abstract query" becomes "SPARQL Query"

Yes, that seems a good idea. Cheifly the first is
most important I think, the BGP def should be
with the other pattern defs.

 >
 >Swapping 12.1. and 12.2 is possible but 12.2
 >uses some of the defined terms like triple
 >pattern.

Yes, I thought of this after I sent it. Sigh.

 >
 >Not swapped for the moment.
 >
 >>
 >>In fact, I would suggest switching sections
 >>12.1 and 12.2, and maybe merging 12.1 with 12.3.
 >>
 >>12.1.1
 >>
 >>"IRIs, a subset of RDF URI References that
 >>omits spaces." Is that *really* the definition
 >>of an IRI? Suggest provide a link to the IRI
 >>publication.
 >
 >Added ref to [RFC3987]
 >
 >>
 >>The link on the word 'updated' is to
 >>http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref.
 >>Is this the most appropriate link?
 >
 >Isn't this where "RDF URI Reference" is defined
 >in the RDF core specs?  It's not in MT at all.
 >
 >(err - MT uses "URI references" which is
 >different again yet says they are resolved by
 >that point. Rat hole.)

Yes, rat hole. Forget it.

 >
 >>
 >>First definition: et -> Let
 >>
 >>12.1.2
 >>"each <ui> is an IRI. Each <ui> is distinct."
 >>-> "each  <ui> is a distinct IRI."
 >>
 >>The notation used here seems odd to me.
 >>Usually, ordered pairs are indicated using <>
 >>as brackets. Why do you need them round the IRI
 >>names? Wouldnt it make sense to write this in
 >>this way
 >>"An RDF dataset is a set:
 >>{G, <u1, G1>, ...}..."
 >
 >URIs/IRIs are written with <> as delimiters.
 >These <> are being used to indicate IRIs.
 >Conflict of conventions :-)

Yes. I tried to find some unicode math symbols
for more math-looking angle brackets, but gave
up. I know they are in there somewhere. Trouble
is when one gets too clever, old browsers break.

 >
 >>
 >>12.1.3
 >>"...is a member of an infinite set V which is disjoint from RDF-T. "
 >>
 >>You don't give a definition for BGP (its a set
 >>of triple patterns, yes?) I suggest it should
 >>be between 12.1.4 and 12.1.5. Right now there
 >>is no connection between the material up to
 >>12.1.4 and the stuff starting at 12.1.5. Also,
 >>the internal link
 >>http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#rBasicGraphPattern
 >>is broken.
 >
 >BGP defined in 12.3.1 - moved to 12.1.4.
 >
 >>
 >>12.1.5 seems a bit bare. Where do we find out
 >>more about these various kinds of pattern?  Can
 >>you provide links? (As you do in 12.1.7)
 >
 >Section removed as no longer needed.  It all
 >goes via algebra expressions in the definition
 >of SPARQL.

OK, better.

 >
 >>
 >>12.1.6. (Question about terminology. Is *every*
 >>such mapping a "solution" mapping? Or only the
 >>ones which actually are solutions? Right now we
 >>say the first, which seems a bit odd to me,
 >>because a solution mapping might not be a
 >>solution. (Later. Was it me who suggested this
 >>terminology? If I did, mia culpa again.))
 >>
 >>No need to say from V to T since these are globally fixed.
 >>-> "A solution mapping Ô  is a partial function Ô  : V -> T"
 >
 >Done.
 >
 >>
 >>The note about multisets seems out of place
 >>here, since we havnt mentioned matching graph
 >>patterns yet, and nothing has been said about
 >>there being multiple answers. Suggest moving
 >>this to 12.2, and omitting the last sentence
 >>"It is described..." which reads like an
 >>implementation suggestion and seems out of
 >>place. Readers will likely know what a bag is
 >>in any case, right?
 >
 >Moved but retained the definition as
 >set+cardinality function.  That is what a  a
 >multiset is - and we use that form in the work
 >later on

Yes, I saw that and meant to go back and remove
this deletion suggestion. Sorry, I was getting
tired.

 >so worth mentioning it.
 >
 >http://planetmath.org/encyclopedia/Multiset.html
 >http://en.wikipedia.org/wiki/Multiset
 >
 >>
 >>12.1.7 What is a solution sequence, that we can
 >>have a modifier of it? Is there a missing
 >>definition of 'solution sequence' ?
 >
 >Added but all it says is a "solution sequence" is a sequence of solutions.
 >
 >"A solution sequence is a list of solutions, possibly unordered."
 >
 >Better suggestions?

No, thats fine. Probably anyone sane would
understand it anyway, but I was being very anal
about definitions.

Pat
-- 
---------------------------------------------------------------------
IHMC  (850)434 8903 or (650)494 3973   home
40 South Alcaniz St. (850)202 4416   office
Pensacola   (850)202 4440   fax
FL 32502   (850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 19 March 2007 16:57:54 UTC