Re: More definition questions/suggestions

These changes as noted go into v1.327.


Bijan Parsia wrote:
> Working off:	
> <http://www.w3.org/2000/06/webdata/xslt? 
> xslfile=http%3A%2F%2Fwww.w3.org%2F2001%2Fsw%2FDataAccess%2Frq23%2Fdefns. 
> xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2001%2Fsw%2FDataAccess%2Frq23%2F&a 
> uth=proxy&transform=Submit>
> 
> ---------------
> """Definition: RDF Term
> 
>   An RDF Term is anything that can  occur in the  RDF data model."""
> 
> "RDF data model" is linked to section 3.1 (Graph Data Model) of the  
> Concepts and Abstract Syntax document. That section is non-normative.  
> The first line is also redundant, given the rest of the definition:
> 
> """ let RDF-U be the set of all  RDF URIs
>   let RDF-L be the set of all  RDF Literals
>   let RDF-B be the set of all  bNodes
> 
>   The set of RDF Terms, RDF-T, is RDF-U union RDF-L union RDF-B."""
> 
> So, I advise striking it or moving it to the explication text instead  
> of the definition.

Moved to just after definition box.
(Definitions should all have anchors now by the way but there is further 
neatening of content markup to do.)

> 
> (It's possible to read section 3.1 so that "triples" can occur in the  
> RDF data model, yet it's clear that triple are not, themselves" RDF  
> Terms.)
> 
> ---------------
> """Definition: Query Variable
> 
>   Let V be the set of all query variables. V and RDF-T are  disjoint."""
> 
> This doesn't look like a definition (i.e, there is no "such that"). It  
> also not specified whether V is non-empty, and whether V is  
> denumerable. Section 6.6 of C&AS makes these features clear for blank  
> nodes:
> 	http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-blank- 
> nodes
> 
> Perhaps this definition could read similarly, e.g.,
> 
> "A query variable is a member of the set V where V is infinite and  
> disjoint from RDF-T. V is otherwise arbitrary."

Done.

> 
> The other possibility is to pick a non-arbitrary set with the desired  
> features. E.g., V is the set of pair whose first element is the unicode  
> string "?" and whose second element is an arbitrary unicode string. I  
> believe such a V is disjoint from RDF-T, though you might make the type  
> tag "<?>" to rule out bizarre uris of the future :)
> 
> (BTW, is there a strong motivation for the RDF- prefix? It seems otiose  
> and is hard to read, IMHO)

The idea is to stress what is RDF and what is SPARQL - "RDF-" are not defined in 
this doc (modulo RDF-T which is not in RDF but is a simple consequence).

> 
> ---------------
> It would be good to note in the comment on triple patterns with literal  
> subjects that all Query Patterns will literal subjects will *fail* on  
> any RDF document. I'm fine with them being legal in SPARQL, perhaps as  
> a forward compatibility measure, but it's also nice to note their  
> (current) futility.

Notes that triple patterns with literal subjects don't match.

> 
> ---------------
> """Definition: Query Pattern
> 
>   A query has one main graph pattern. It is called the Query Pattern."""
> 
> There is no definition of Query.

There is now a section (to be numbered in) that provide basic definitions.

> 
> There is no definition of Graph Pattern. (Basic pattern and Graph  
> Pattern -- Grouping, yes. See my earlier message).
> 
> Can there be more than one main graph pattern? Are there non-main graph  
> patterns? What's the difference?
> ---------------

A query has at most one main graph pattern.  "The query pattern".

> 
> Ok, taking a break now. Foward looking a bit I see there's some  
> sloppiness with the term "pattern". For example:
> 
> "Definition: Constraints
> 
>   A pattern may be a constraint, which is a boolean-valued expression of  
> variables and RDF Terms that restricts query solutions"
> 
> "A pattern"? A triple pattern? A graph pattern? Are constraints  part  
> of Basic Patterns? (in which case, shouldn't they be part of the  
> definition of basic pattern?) I'm afraid that order of exposition is  
> getting in the way here.

Once upon a time, constraints could be triple patterns (including liteal 
subjects) but while some constaints can be represented as properties in some 
systems, not all systems provide these.

Hence, now, constrainats are treated as restrictions of values, not as patterns. 
  This also means it is clear(er) that a SPARQL engine might provide constraints 
without full D-entailment in pattern matching.

> 
> More later, I imagine.
> 
> Cheers,
> Bijan.

Sorry it has taken so long to incorporate these suggestions.

	Thanks
	Andy

Received on Friday, 29 April 2005 14:18:03 UTC