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

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 England

Received on Thursday, 22 March 2007 15:36:40 UTC