From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Tue, 03 May 2005 13:33:42 +0100

Message-ID: <42776FA6.4040809@hp.com>

To: Bijan Parsia <bparsia@isr.umd.edu>

CC: DAWG Mailing List <public-rdf-dawg@w3.org>

Date: Tue, 03 May 2005 13:33:42 +0100

Message-ID: <42776FA6.4040809@hp.com>

To: Bijan Parsia <bparsia@isr.umd.edu>

CC: DAWG Mailing List <public-rdf-dawg@w3.org>

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 AndyReceived on Tuesday, 3 May 2005 12:34:30 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:00:47 UTC
*