Re: [Fwd: Re: my take on the formal semantics of SPARQL]

Andy Seaborne wrote:

Blank nodes and identifiers:

These form a significant part of the proposal.  It would seem that if we can 
sort out what is happening as given by section 2.5, the other comments about 
blank nodes will be more readily addressed.  Pat has offered to review the 
language on blank nodes/blank node identifiers.

I reply: Sounds good; I am awaiting his contribution.

*******************************************************

Andy Seaborne wrote:

1/ Proposal sections 3.4, 3.6, 3.8

One of the key themes here is the relationship of syntax and definition.  I 
agree that rq23 is weak on this.  Correct me if I'm wrong but you seem to 
propose that the syntax is used to drive the definitions whereas currently 
there is a collection of abstract definitions, then there is a syntax.  Would 
it instead work to add ties from the sections with abstract definitions 
referencing the grammar?

I prefer this because there may be future different syntax forms (e.g. XML or 
RDF): by keeping the abstract definitions central, these can be reused with 
different mapping to syntax.  Also, some communities are interested only in 
the abstract definitions, not the syntax.

I reply:

That is fine with me if we want to permit alternative syntax, or
be helpful to those only interested in abstract semantics.
My point is that we do need to have explicit connections between
our syntax and the abstract semantics.  That will be equally 
applicable of any alternative syntax that is proposed.

*******************************************************

Andy Seaborne wrote:

2/ Cardinality of a solution.

I do not understand the use of this terminology.  A solution is a mapping of 
variable to RDF terms so that the pattern is true on the dataset.  Is 
cardinality the number of variables mapped or the number of such solutions?

For example in 3.18, if condition 2b hold the cardinality is one.  I don't see 
why the cardinality of S is constrained by condition 2b?  If cardinality is 
counting the number of solutions, I would have thought the cardinalities where:

If 2a) , then cardinality(optional) = cardinality(S) If 2b) , then 
cardinality(optional) = sum over all solutions S * cardinality(T given S).

I reply:

This goes back to my conclusion that the first argument of an OPTIONAL
is always a FilteredBasicGraphPattern.  Solutions for such patterns
always have cardinality 1, so it is possible to simplify the product.

However, in a separate private thread you have responded that the 
first operand is not necessarily a FilteredBasicGraphPattern.
This is concerning the example on page 15 of my paper.
My issue is that the grammar
implies that the BNF nonterminal immediately before OPTONAL is 
always a FilteredBasicGraphPattern.  In the example, of the form
{ P1 } UNION { P2 } OPTIONAL { P3 }, we get an empty 
FilteredBasicGraphPattern between { P2 } and OPTIONAL, which I 
construe as the first operand of OPTIONAL.  It seems that an 
existing parser disregards that empty pattern and reaches back to
the UNION for the first operand.  
I need to understand this more deeply. 

************************************************

Andy wrote:

3/ Section 3.18

The significant change here is where S is required not to be defined on the 
variables (variables introduced by ...) GGP.  This rules out the query:

"Get the name if there is one, else get the email address, else ..."

or
    { ... ?x .... }
    OPTIONAL { ?x foaf:name ?displayLabel }
    OPTIONAL { ?x foaf:mbox ?displayLabel }

because S may be defined on ?displayLabel yet not match (and hence not 
introduced new bindings for other variables) on the right hand side of the 
optional.  Have I understood correctly?

I reply:

you have understood my proposal.  Note though that I am not 
committed to my proposal; I merely wrote it to advance the 
discussion.  I would be interested in seeing alternative well-specified
formal definitions of OPTIONAL so that we can contrast them and 
choose the best.

Fred

Received on Wednesday, 21 June 2006 18:43:43 UTC