- From: Fred Zemke <fred.zemke@oracle.com>
- Date: Wed, 21 Jun 2006 11:43:30 -0700
- To: public-rdf-dawg@w3.org
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