Re: version for review

Patrick Stickler wrote:
> I think it's OK for bnodes to name graphs, but not for
> bnode graph names to span graphs.

I am convinced, does this leave bnodes as graph names as useless ... there 
are further difficulties in the semantics that I need to raise.
Both Chris and Pat argue for URIrefs only as graph names.
(I'll send a further msg detailing the problem I have found)


Most of the detailed points I say "OK" or something, which means yes this 
looks like a good point, I'll work it into the text and/or get back to you 
on it.

> 
> Section 2, para 1:
> 
> I think we need to constrain bnode graph names to statements
> occurring within that particular graph itself. I.e., if you
> need to make statements about a graph in *another* graph, you
> must use a URI.
> 
> Your examples in section 8 have statements where the subject
> is the bnode label of another graph, and I don't think that's
> valid (or should be valid) because it suddenly turns bnodes
> into global identifiers just like URIs when they are used
> as graph names.
> 
While I disagree with the argument I agree with the conclusion, so I won't 
discuss the argument.


> -- 
> 
> Section 4: "using the URL from which an RDF/XML file is retrieved
> as a name for the graph"
> 
> Perhaps it would be better to use the xml:base, if defined, thus
> avoiding some of the problems where the same document may be
> returned as a representation when resolving various URIs which
> may not in fact denote the graph in question. ???

Unfortunately there is no such thing as *the* xml:base, an RDF/XML document 
can have many xml:base's defined within it.

> Section 4: use of parentheses
> 
> Perhaps we should use curly brackets rather than parentheses
> to be more compatible with N3/Turtle, which use parentheses
> for collections.

I am easy - parentheses as opposed to braces was Chris's choice - I'll let 
him argue the case (if he wishes to).

> 
> -- 
> 
> Section 6:
> 
> Not that we need to mention this in the paper along with the plug
> for TriQL (though feel free to do so if you like ;-) ... but
> 
> The definition for RDFQ [1] also now supports named graphs (or
> will, once I get around to updating it ;-)
> 
> [1] http://sw.nokia.com/rdfq/RDFQ.html
> 
> The rdfq:Query instance can have any number of rdfq:graph's
> defined, which constitute a form of "pre-query" to identify
> all graphs which match any of the specified templates, after
> which, the target templates are applied to the set of matched
> graphs. I.e.
> 
> rdfq:inGraph a rdf:Property;
>    rdfs:domain rdfq:Query;
>    rdfs:range rdfg:Graph;
>    rdfs:comment "A template constraining the query to only matching 
> graphs.".
> 
> [a rdfq:Query;
>    rdfq:graph  [a rdfq:Graph; swp:assertedBy [a swp:Warrant; 
> swp:authority [foaf:email <mailto:john.doe@example.org]]];
>    rdfq:graph  [a rdfq:Graph; swp:assertedBy [a swp:Warrant; 
> swp:authority [foaf:email <mailto:mary.smith@example.org]]];
>    rdfq:target [a rdfq:Target; dc:created [a rdfq:Value; rdfq:lt 
> "2004-02-02"^^xsd:date]]].
> 
> or minimally
> 
> [:graph  [swp:assertedBy [swp:authority [foaf:email 
> <mailto:john.doe@example.org]]];
>  :graph  [swp:assertedBy [swp:authority [foaf:email 
> <mailto:mary.smith@example.org]]];
>  :target [dc:created [:lt "2004-02-02"^^xsd:date]]].
> 
> I.e. find resources created before 2004-02-02 from graphs asserted by 
> either John Doe
> or by Mary Smith.
> 
> There can be any number of graphs specified, and for those that match 
> the specified
> criteria, the templates are then applied only to statements in those 
> graphs. I.e. first
> identify all matching graphs, then all matching targets within those 
> graphs.
> 
> If no graph is specified, then the templates are applied to all/any graphs.
> 
> If one is able to infer class membership of graphs as trusted and 
> asserted, then one
> can qualify all queries easily as:
> 
> [a rdfq:Query;
>    rdfq:graph [a x:TrustedAssertedGraph];
>    rdfq:target [a rdfq:Target; dc:created [a rdfq:Value; rdfq:lt 
> "2004-02-02"^^xsd:date]]].
> 
> or minimally
> 
> [:graph [a x:TrustedAssertedGraph]; :target [dc:created [:lt 
> "2004-02-02"^^xsd:date]]].
> 
> I.e., find resources created before 2004-02-02 according to claims made 
> in trusted,
> asserted graphs.
> 
> If one simply wants all of the dc:title values for such resources, 
> rather than
> complete descriptions of the matched target resources, the property 
> rdfq:select
> can be used, and the results are expressed as variable bindings using the
> Result Set Vocabulary:
> 
> 
> [:select ( "title" );
>  :graph  [a x:TrustedAssertedGraph];
>  :target [dc:created [:lt "2004-02-02"^^xsd:date];
>           dc:title   [:id "title"]]].
> 
> One of the nice things about the way RDFQ handles this in vocabulary is 
> that
> the actual syntax of RDF/XML, N3/Turtle does not have to change in order to
> express graph-specific queries.
> 
> -- 


Another reference is good, I'll trim your text down (possibly just to a 
single phrase)

> 
> Section 7:
> 
> The example should be terminated with an extra statement in
> graph G5 so that the provenance chain is bounded:
> 
> G5 (...
>     G5 dc:creator Peter .)
> 
OK


> -- 
> 
> Section 8.1: bnode graph names
> 
> As mentioned above, you have bnode bindings spanning multiple graphs,
> which I don't think should be valid. The use of _:g1 in graph _:h
> should have no meaning outside of graph _:h and thus does not in
> fact refer to graph _:g1 since the bnodes of graph _:h are disjunct
> from the bnodes of graph _:g1.
> 
> A bnode graph name is only relevant to statements within that graph, IMO.
> 
> Better to just use URIs in these examples. In fact, I think we should
> consider it a best practice to use URIs to name graphs rather than
> bnodes.

Best practice = let's change it now and drop bnodes as graph names?

> 
> Thus:
> 
> G, G1 (...)
> 
> H (...
>    G1 swp:quotedBy _:w2 .
>    ...)
> 
> -- 
> 
> Section 8.1: "We require [the value of the swp:signatureMethod property]
> to be a literal URI, which can be dereferenced on the Web..."
> 
> Question, what is the difference between a URI and a literal URI? Do
> you mean rdfs:range xsd:AnyURI?
> 

xsd:anyURI I think - a literal URI denotes itself in the RDF Model Theory 
and hence can then be used for dereference operation, whereas a URIref node 
denotes a resource, presumbably the same resource as that for which you get 
a representation when you dereference it, but that takes us well into the 
social meaning issue, that we are trying to skirt around.

> Also, while requiring the signature method to be denoted by a URI,
> I don't think we need to go so far as to require that the URI be
> web-dereferencable. It's *convenient* if it is dereferencable, and
> it's probably a "best practice" for it to be dereferencable, but
> I don't see it as an actual requirement. As long as the publisher
> and consumer understand the URI in the same way, that's all that
> counts.
> 

That's technically correct, however in practice there will only be a 
handful. For the paper I am inclined to leave it as required, it simplifies 
the explanation without any real great loss of generality. Without the 
document it is much harder to write the semantics of signature which does 
actually depend on the method indicated (and if that method is by private 
agreement then it is slightly awkward!)

> -- 
> 
> Section 8.2, last para, last sentence:
> 
> Consider changing "...some of their RDF does include its own assertion"
> to "...some of their graphs do include their own assertion", which
> I think is what you mean and what we want to say. "their RDF" is
> pretty broad...

I'll look at this.

> 
> -- 
> 
> Section 10:
> 
> I'm OK with your proposal to delete and address elsewhere.
> 
Chris likes that idea, so I think does Pat ...


> -- 
> 
> That's all. The rest reads pretty good to me. I especially appreciated
> the use case of syndication showing where assertion vs. quoting is
> useful.
> 
> Patrick
> 

Jeremy

Received on Tuesday, 30 March 2004 06:11:13 UTC