Re: More definition comments

Bijan Parsia wrote:
> Continuing.
> 
> (In basic pattern, I guess it goes without saying that a basic pattern 
> is a *finite* set of triple pattens?)

In what way does it matter?  RDF graphs are a set of triples without that 
restriction aren't they?

> 
> --------------
> ""Definition: Substitution
> 
> Substitution is a function from a subset of the set of variables, V, 
> the domain of the substitution, dom(S), to the set of RDF terms, T.
> 
>   We write S(v) for the substitution of variable."""
> 
> Proposed revision
> 
> """**A** substitution is a relation from a subset of V, its 
> <em>domain</em>,to RDF-T.
> 
> We write dom(S) for the domain of a substitution.
> 
>   We write S(v) for the substitution of **a** variable."""
> 
> (The articles definitey need to get in there.)

Done.

> 
> (If the editors want to keep "the set of variables V" etc. for clarity, 
> that's fine. But it definitely should be either T or RDF-T everywhere.)
> 
> (I have a worry about the S(v) notation, but will take it up below.)
> 
> --------------
> """Definition: Restriction
> 
>   If X is a subset of dom(S) and dom(S')=X and S'(v) = S(v) for all v in 
> X then S' is the restriction of S to X, written S|X."""

There is no use madxe of this and it had already been removed.

> 
> First, where are restrictions used? I see the word used in constraints 
> but it doesn't seem to be doing the same thing (i.e., there it is a 
> restriction on the *ranges*, not of the domain of a substitution).
> 
> Second, the definitoin and notation are confusing. Esp. if unused :) 
> Here's a revision:
> 
> "The substitution R is a restriction of S if dom(R) is a subset of 
> dom(S) and for all v in dom(R), R(v) = S(v). R is known as the 
> restriction of S to dom(R), and written rest(S, dom(R))."
> 
> Ok, the recursion on dom(R) is a bit ugly, but I'm unclear why we need 
> the restriction of Foo *to* Bar in the first place.
> 
> --------------
> 
> """
> Definition: Pattern Instance
> 
>   If S is a substitution then the result of replacing any v in a basic 
> pattern P by S(v) is a pattern instance of P, written S(P)."""
> 
> So, pattern instances don't have to replace all their query variables? 
> In other words, not all pattern instances are rdf graphs, but some are 
> themselves patterns?

Pattern instances should replace all variables in dom(S).

> 
> Where are pattern instances used?

I'll check - they (used to?) come up in definitions of graph operators but if it 
isn't there anymore, then this can go.

> 
> BTW, I find having S(v) and S(P) mean different things *frightfully* 
> confusing. Also, S(P) isn't even a function according to the above 
> definition, since, given that S is
>   	?x = ex:foo
> 	?y = ex:bar
> 
> and a basic pattern
> 	(?x ex:baz ?y)
> 
> S(P) can be (ex:foo ex:baz ?y) and (?x ex:baz ex:bar) and (ex:foo 
> ex:baz ex:bar). Is that 'any' up there supposed to be an 'every'? (Or 
> read with the force of an 'every', as in 'any variable in P is replaced 
> by S(that variable)'?

s/any/every/

> 
> I asked someone else how they read it and they read it the same as me. 
> (Note, I may have biased the reading.)
> --------------
> """Definition: Pattern Solution
> 
>   A Pattern Solution of Graph  Pattern GP on graph G is any substitution 
> S such that S(GP) is a subgraph of G."""
> 
> Undefined (and unlinked), Graph Pattern, graph, and subgraph. Note that 
> the last two are defined:
> 	http://www.w3.org/TR/rdf-mt/#graphdefs
> 
> and are the same *assuming* that S(P) goes to graphs, not basic 
> patterns. Which I guess it must or this all makes no sense :)
> 

There were two styles here and I thin, implicitly it is changing from one to teh 
other:

Originally, the definitions were partial and built up through the docuemnt - no, 
or few/short, forward references.

Now, the definitions are complete but with forward references.
This does make the document odd in that the examples/narrative build 
progressivley, the definitions do not but I think it works better than a 
complete separation.

rdfs:seeAlso:

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Apr/0000.html

> --------------
> 
> I'm very unclear how bnodes play out. It seems to me that any query 
> with a blank node cannot have a match. On the one hand:
> 
> "Blank Nodes and Queries
> 
> A blank node can appear in a SPARQL query patterns. It behaves as a 
> variable,  although it can not be named in the query result form, such 
> as SELECT."
> 
> But it can never appear in a substition (given the definition of 
> substitution and the disjointness of V from RDF-T). I presume that 
> bnodes in query patterns are distinct from bnodes in the queried graph, 

Yes.

> regardless of their lexical form, thus any Graph Pattern (GP) with 
> bnodes will lack any pattern solutions, since every S(GP) will fail to 
> be a subgraph of any other graph (at least, given the RDF Semantics and 
> the obvious meaning of subgraph).

Would need

> One could get around this by saying:
> 
> """A Pattern Solution of Graph  Pattern GP on graph G is any 
> substitution S such that S(GP) is simply entailed by G."""
> 
> Or if one is adverse to simple entailment, one could say:
> 
> """A Pattern Solution of Graph  Pattern GP on graph G is any 
> substitution S such that there is a subgraph of G which is an 
> RDF-semantics-instance-of S(GP)."""

It should be subgraph, not entailment. bNodes in the query, as varibales, need 
to be matched and substituted.  Any bNode in S(P) is going to have to be a bNode 
fom the target graph to get a subgraph match.

I've noted that pattern solution is (now) the defintion of matching a basic 
pattern.  Proper integration will happne when I can do a complete defintions 
pass and can incorporate comments/2005Apr/0000.

> 
> One could also expand the definition of Substitution, or of variables. 
> We've already liberalized the subject position, why not liberalize the 
> predicate position as well?

That's probably a good idea now.

Liberalizing the subject position does not change much (it can't match) but 
adding bNodes-as-variables to the property position does expand things.  It 
woudl not need an extension to the RDF MT because they can only be used for a 
match and such a blank node is distinct from the target graphs.

> 
> (Ok, I actually don't really want predicate variables to be bnodes 
> because I want to generate a OWL Direct model theoretic compatible 
> semantics, in which predicate variables are, in fact, metalinguistic. 
> But it is a solution. I don't think it'd be hard to extend the RDF 
> model theory to handle this extension.)
> 
> (Bedtime!)
> 
> Cheers,
> Bijan.

	Thanks
	Andy

Received on Tuesday, 3 May 2005 12:34:30 UTC