Re: Comments on WD

On Oct 12, 2006, at 1:55 PM, Seaborne, Andy wrote:

> Bijan Parsia wrote:
[snip]
>> http://www.w3.org/TR/rdf-sparql-query/#basicpatterns
>
> Could we work of the editors' draft please?
> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html

Sure.

>> Is this section normative or informative? If it is informative,  
>> it  should be marked as such. It looks as if it is meant to be  
>> informative.
>
> Added "This section gives an introduction to the basic matching  
> features of SPARQL."  I'd like to add a sections for the other  
> graph pattern matches but it'll depend on time.

In some W3C documents I've worked with, the header has an (Non- 
Normative) parenthentical, e.g.,
	http://web5.w3.org/TR/wsdl20/#Syntax-Summary
(Shows up in the TOC)

I guess my real point is whether we are going to adopt that style. I  
see in rdf revised syntax:

http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax

"""This section introduces the RDF/XML syntax, describes how it  
encodes RDF graphs and explains this with examples. If there is any  
conflict between this informal description and the formal description  
of the syntax and grammar in sections 6 Syntax Data Model and 7 RDF/ 
XML Grammar, the latter two sections take precedence.""""

I think it has to be at least that explicit, but I much prefer the  
heading approach since it's usefully directive (i.e., people will  
skip to and around non-normative sections as their needs dictate).

I don't know if the W3C has a global style policy on this, at the  
moment...Eric?


[snip]
>> Given the complexity of the operator, the example is just sugar  
>> for a  directly expressed exact match.
>
> XQuert/Xpath regular expressions are not anchored unless explicitly  
> done so wityh ^ and $.  So it's not equality match - it's substring.

Right, that's what I didn't get right away. Looking back, this text:

""""Only plain literals with no language tag and XSD strings are  
matched by regex. regex can be used to match the lexical forms of  
other literals by using the str operator."""

made me think that the whole string had to match (e.g., that it was a  
test of language inclusion). Granted, I'm not the best test for  
this :) Give that we use "matching" a lot elsewhere (where it's  
usually equality/inclusion) matching, it might help to call things  
out here differently.

>> The second query seems wrong:
>> PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
>> SELECT  ?title
>> WHERE   { ?x dc:title ?title
>>            FILTER regex(?title, "web", "i" )
>>          }
>> That shouldn't match "The Semantic Web" should it? I clicked on   
>> "regex" and got to a function fn:matches (wha?) Ok, we renamed it.
>
> fn:matches (from F&O) is the backing function for regex in the same  
> way that "+" is backed up by fn:numeric-add.

Yes, I got that. It was just disorientating.

>> (Bit scary.) Oh I see, it's not "is this string an instance of  
>> this  regular expression", but "is there a substring which is in  
>> that  expression". er...ok. Pretty standard I guess if you are  
>> using  "matches". I felt quite lost in the XSD document, which is  
>> par for  the course, but wouldn't it make more sense to indirect  
>> through a  description by us? In fact, through:
>> 	<http://www.w3.org/TR/rdf-sparql-query/#funcex-regex>
>
> Yes - link with the document to the sec 11 section #funcex-regex
>
>> I mean, *normal* references are routed through the references  
>> list, a  practice which annoys me about w3c specs, but here is a  
>> good case  where seeing our text is essential.
>
> We do some linking to external docs where it is not a reference,  
> but is helpful.  For references, we do the W3C style thing.

Right but in this case, I was totally lost by the jump to the XSD  
function that didn't have the same name. In that case, it would be  
much easier to see our text rather than directly jump to the backing  
function. (I.e., the link doesn't explain that it's a backing  
function, etc. so I thought it was a mislink at first).

>> (I think that putting numbers first would be easier.)
>> (And do we want to use the phrase "matches" here? Esp. since we   
>> changed the name of the function :))
> >
>> (Sorry, not reviewing 2.6. I have a policy of not reading  
>> anything  about reification :))
>
> It's not about reification so much as about the fact we don't do  
> anything special about it!

Hmm. Have we considered just having:

	"Yo! We don't give you any reification special joy. Suck it up."

:)

>
>> ======
>> """Blank nodes in the results of a query are from the scoping  
>> set,  but this information cannot be used by an application or  
>> client which  receives these results, since all blank nodes in  
>> subsequent queries  are treated as being local to that query. In  
>> effect, this means that  information about co-occurrences of blank  
>> nodes may be treated as  scoped to the results as defined in  
>> "SPARQL Query Results XML Format"  or the CONSTRUCT result form."""
>> So, no one knows what a scoping set is at this point. And it's  
>> not  necessary to know. How about:
>> "Blank nodes are local to the result set of a query. That is,  
>> blank  node labels in distinct SPARQL query Results XML Format or  
>> construct  result form documents do not refer to the same BNode.  
>> This means that  one cannot usefully use BNode labels in a result  
>> form to formulate a  new query about *that* BNode."
>
> Yes - it should be blank node labels.
>
> The same label in the same result (XML doc or RDF graph) does refer  
> to the same blank node.
>
> Section title changed to:
> """Blank Node Labels in Query Results"""
>
> and text changed to:
>
> """
> The presence of blank nodes in query results can be indicated by  
> labels in the serialization of query results.
>
> Blank nodes labels are local to the result set of a query. An  
> application or client cannot usefully use blank node labels to  
> formulate a query that directly refers to a particular blank node.   
> In effect, this means that information about co-occurrences of  
> blank nodes may be treated as scoped to the results as defined in  
> "SPARQL Query Results XML Format" or the CONSTRUCT result form.
> """

That's fine.

> Probably have to come back to this text when the BGP defn is  
> revised to make sure there is no confusion.

Agreed.

Thanks for the updates.

Cheers,
Bijan.

Received on Thursday, 12 October 2006 13:21:16 UTC