From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Thu, 22 Mar 2007 15:36:28 +0000

Message-ID: <4602A27C.1050609@hp.com>

To: Pat Hayes <phayes@ihmc.us>

CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Date: Thu, 22 Mar 2007 15:36:28 +0000

Message-ID: <4602A27C.1050609@hp.com>

To: Pat Hayes <phayes@ihmc.us>

CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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. ... > 12.4 > > Definitions here all refer to 'mappings'. As we > have defined a number of different mappings, say > which one of them is intended. Now uses "solution mapping" > Defn of filter: "an expression that has a boolean > effective value of true" Is this verbiage really > necessary? You havn't used the phrase "boolean > effective value" elsewhere. Why not just say "an > expression with the value true" ? "effective boolean value" is used in section 11.2.2 Evaluation of an expression is turned into a boolean value by the BEV rules (which are directly from XML F&O). * If the argument is a typed literal with a datatype of xsd:boolean, the EBV is the value of that argument. * If the argument is a plain literal or a typed literal with a datatype of xsd:string, the EBV is false if the operand value has zero length; otherwise the EBV is true. * If the argument is a numeric type or a typed literal with a datatype derived from a numeric type, the EBV is false if the operand value is NaN or is numerically equal to zero; otherwise the EBV is true. * All other arguments, including unbound arguments, produce a type error. But it should be "effective boolean value", which I've fixed. > > Is "card[Filter(expr, â¡)](Ã ) = card[â¡](Ã )" > really true? Surely the filter can reduce the > cardinality, no?? No - not the cardinality. It wouldn't be in the domain of the cardinality function if it's been removed. The cardinality function is multiplicity of a given mapping, not the size of the whole multiset. Cardinality is never zero - removing something is removing it from the set. > Defn Join: "sum over Ã in (â¡1 set-union â¡2), > card[â¡1](Ã 1)*card[â¡2](Ã 2)" What does this mean? > The sum expression doesnt contain Ã . card[Join(Î©1, Î©2)](Î¼) = sum over Î¼, where Î¼ = merge(Î¼1, Î¼2), in (Î©1 set-union Î©2), card[Î©1](Î¼1)*card[Î©2](Î¼2) The same Î¼ may occur for different choices of Î¼1, Î¼2. (I was avoiding writing big sigma here because I don't know how to typeset it in HTML in any sort of portable way). > > Defn. Diff; again, is that equation for the cardinality really true? > Similarly for the union case: surely one only > gets the sum of the cardinalities when the > original sets are disjoint. Diff: A solution mapping in the diff is ony there if it is in the LHS (Î©1). It's cardinality is the same as the LHS cardinality (cardinality of zero is not how elements are excluded - they just aren't in the set part of the multiset). Union: yes - it's additive (which is not the definition of "union of multisets", which is max()). > > Is the C in [x | C] a condition on the sequence > or on the elements of the sequence? """ Write [x | C] for a sequence of elements where C(x) is true. """ ---- Swapping Distinct and Project to be the order they are elsewhere. > --------- > 12.5 > > What is the range of eval? Its hard to read > expressions like "Join(eval(D(G), P1), eval(D(G), > P2))" without knowing this :-) Good point! > > What is the "active graph" exactly? (See first comment.) > > Its not clear (to me) what it means to say that > the active graph is "initially" the default > graph. (Initially? How did time get into the > question?) Not just editorial - will clear up in an "active graph" pass. > > Suggest > "eval(D(G), BGP) = multiset of solution mappings" > -> "eval(D(G), BGP) = multiset of all distinct > solution mappings for BGP from G" (assuming that > the earlier suggested changes are made so this > makes sense.) There can be repeated solution mappings (if there were blank nodes in the pattern). (need to send email now because we have CVS merge problems). > > Defn of Evaluation of a Union Pattern. "join" is > written in lower case. Should this be "Join" ? > > BTW, this would all be a lot easier to understand > if you used some systematic way of distinguishing > the evaluation function from the SPARQL algebra > term, say by a font change or something? But its > getting late, so never mind.... > > --------- > 12.6 > > "needless of inappropriate" -> "needless or inappropriate" > > "... if and only if the triple (" ends a line, which is a pity. > > "consistent source document SD is uniquely > specified and is E-equivalent to SD." > -> > "consistent active graph AG is uniquely specified and is E-equivalent to AG." > > "For any basic graph pattern BGP and pattern solution P" > -> > "For any basic graph pattern BGP and pattern solution mapping P" > > "and answer set {P1 ... Pn} " -> "and answer sequence <P1 ... Pn>" > > "and where {BGP1 .... BGPn} is a set of basic > graph patterns" -> "and where <BGP1 .... BGPn> is > a sequence of basic graph patterns" > > "guarantee that every BGP and SD" -> "guarantee that every BGP and AG" > > "(a) SG will often be graph equivalent to SD" -> > "(a) SG will often be graph equivalent to AG" > > "that SG share no blank nodes with SD or BGP. In > particular, it allows SG to actually be SD." > -> > "that SG share no blank nodes with AG or BGP. In > particular, it allows SG to actually be AG." > > "graph-equivalent to SD but shares no blank nodes with SD or BGP" > -> > "graph-equivalent to AG but shares no blank nodes with AG or BGP" > > ----------- > > Phew. > > Pat > -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 EnglandReceived on Thursday, 22 March 2007 15:36:40 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:00:53 UTC
*