Re: version for review

On Mar 30, 2004, at 14:10, ext Jeremy Carroll wrote:

> 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'm not opposed, necessarily, to limiting graph names to URIs. One could
fairly argue that the graph names are "outside" of the graph, and thus
can't be bnodes, since bnodes are "inside" the graph. But one could also
argue that graph names are on the "event horizon" of the graph and thus
are both "inside" and "outside" at the same time, and hence can be used
to name the graph, but only to refer to the graph by statements within
the graph.

I'm happy with either approach.

> (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.

Fair enough. It was just a thought.

>
>> 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).

I'm thinking about what will create the least path of resistance
if folks start adopting this -- and compatability with N3/Turtle
seemed to me to be a big win.

>
>> -- 
>> 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)

Oh sure. I didn't mean to propose that the above would go into the 
paper. It was
just for the three of you.

>
>> 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?

OK by me.

>
>> 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.

But wouldn't you be *wanting* to denote the resource, the method itself?
Otherwise, anything said about that method would not be stated in terms
of that URI.

I don't think the range/value should be a literal. I think it should
be the method itself, denoted by a particular URI, which might be
dereferencable (or might not).

>
>> 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!)
>

OK. I won't press the issue. Though I think there's as much potential
for questions/feedback by stating the requirement than by not stating 
it.
But I'll accept it as is.


>> -- 
>> 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
>
>

Patrick


--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Tuesday, 30 March 2004 06:41:38 UTC