- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 12 Dec 2005 13:18:16 +0000
- To: "Eric Prud'hommeaux" <eric@w3.org>
- CC: Dan Connolly <connolly@w3.org>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
Eric Prud'hommeaux wrote: > On Tue, Nov 22, 2005 at 07:36:28AM -0500, Eric Prud'hommeaux wrote: > >>On Tue, Nov 22, 2005 at 11:45:19AM +0000, Seaborne, Andy wrote: >> >>> >>> >>>Dan Connolly wrote: >>> >>>>Andy, you wrote: >>>> >>>>"... There wil be a formal response to your email >>>>when all the comments have been acted on." >>>> >>>>and I'm not sure if anything relevant has happened since then. >>>>Any clues? >>>> >>> >>>All the edit changes (sec 8/9/10) are done from: >>> >>>http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0011.html >>> >>>Eric - what's the status of the comments on sec 11? >> >> >>The first example in 11.2.3.1 for sop:RDFterm-equal should have two results >>in the query results section, with the inverse solution as well as the >>listed, since name1=>Ms A. and name2=>Alice is just as valid a binding. >> >>fixed >> http://www.w3.org/2001/sw/DataAccess/rq23/#conformanceB >> >>The second example in 11.2.3.1 has a typo, the time in the data should be >>19:00, not 19:01 like listed, to get the results expected. >> >>fixed >> http://unagi/2001/sw/DataAccess/rq23/#func-RDFterm-equal >> >>The first example in 11.2.3.2 has several problems, so it's best to >>re-examine it. Namely, the FILTER construct is missing a parenthesis (or >>should have the outside one removed) and the example appears to be >>projecting an undefined variable for no reason. >> >>fixed >> http://unagi/2001/sw/DataAccess/rq23/#func-isBound >> >>The second example in 11.2.3.2 should have foaf:givenName as the predicate, >>not foaf:name. >> >>aha, tx >>fixed >> http://unagi/2001/sw/DataAccess/rq23/#func-isBound >> >>The query under section 11 Testing Values should probably read "?date > ..." >>and not "?date < ...". Otherwise, the same result will be returned in both >>examples, since neither of the dates in the data will test true, no matter >>whether the casting works or not. >> >>fixed >> http://www.w3.org/2001/sw/DataAccess/rq23/#tests >> >>I note that when I ran the LC version, I got no results. >> >>The example in 11.2.3.6 should read "FILTER regex(?name...", not "FILTER >>regex(name..." >> >>fixed >> http://www.w3.org/2001/sw/DataAccess/rq23/#funcex-regex >> >>This may actually present some issues in general, but example 11.2.3.8 has a >>statement ""FILTER (lang(?name) = "ES" ) )"". Technically, "ES" will parse >>to a untyped literal and the LANG function returns a xsd:string, which will >>by the constraints of the language result in a literal compare, which will >>fail in all cases. To be technically accurate, it should read ""FILTER >>(lang(?name) = str("ES") ) )"". > > > Yes, that was the product of excessively sprinkling xsd types where > they weren't needed. I have updated this text to reflect my > implementation and several others (note the announcement and responses > [ST]). The editor's draft now has a new type called "simple literal", > defined as an RDF plain literal with no language tag. The operators > STR and LANG return simple literals; the operators <, >, <=, >=, > langMATCHES and REGEX have forms that take simple literals as > arguments. > > The examples in the spec reflected the actul implementations. They > have not changed. The operator definitions should now be consistent > with the examples (well, they *should* have been consistent before, > but now I think they are). > > > > Andy, does this complete the response to Example Errors? Let me know > if you need anything else. Yes - I had done mine - you can reply as you've covered all the sec 11 ones. (There was a Q about STR function and xsd:string cast constructor which was just a Q.) Andy > > [ST] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/thread#msg304
Received on Monday, 12 December 2005 13:19:24 UTC