Re: Name of a graph? and FROM and FROM NAMED

Yoshio FUKUSHIGE wrote:
> Hi,
> 
> # sorry for the length of this message
> 
> There are some points I found I didn't understand
> w.r.t. FROM and FROM NAMED.
> 
> rq23(rev.1.367) says in  9.1
> [[
> The FROM clause a single URIs that indicates the graph to use as the default 
> graph.
> ]]
> 
> I don't understand this.
> 
> (1) I can't find a verb.
> (2) Does this "URIs" happen to be "URI"?
> (3) Does this "the graph to use as" happen to be "the graph to be used as"?
> 

Corrections made:

"""
The FROM clause contains a single URI that indicates the graph to be used as the
default graph. This does not automatically put the graph in as a named graph; a
query can do this by also specifying the graph in the FROM NAMED clause.
"""

> #OK, the grammatical errors are not what I really point out
> 
> Even so, I don't understand.
> Does this mean that the query issuer can replace the default graph by using 
> a FROM clause?
> (which I don't believe)
> or is it the case
> (3)' "the graph to use as" is really "the graph to be used as a part of"?

Thansk for bringing this up.

There is an issue here which briefly came up in the telecon but got lost other
things.

rq23 does not say, one way of the other, what happens when a service provides a
dataset (so a query with no FROM/FROM NAMED works) and the query contains FROM
or FROM NAMED.

This is a bug.

I propose that if a query contains a dataset description with FROM and FROM
NAMED then these describe the dataset fully (the service wil not sneak in extra,
unasked for, graphs)

Rational: if the application is describing the dataset, then it wants to know
that the query will execute

This is also consistent with the protocol : if the protocol has
default-graph-uri/named-graph-uri it completely overrides what the query might say.


Hence:
  protocol overrides query
  query overrides service provided dataset

Of course, the service may refuse to execute the query if it does not want to,
say it only answers queries about the dataset provided (e.g. Dan's mailing
archive query service example).

If the description of the dataset exactly matches the dataset the service might
go either way.

The other rational is that it is simpler and you can write test cases.


> 
> If so, then why is FROM clause restricted to appear once,

Once upton a time, merging graphs was controversial (blank nodes and all that).
We also had a time when there was no FROM/FROM NAMED but, by popular demand,
they got put back.  I went for a simplest design.

I heard at the telecon significant demand for multiple FROMs and these to create
a merged default graph.

> while FROM NAMED clause is allowed to be appear zero or more times. (A. 
> [10,11] )
> # if this was the thing discussed in the last telecon, sorry
> 
> And there continues
> [[
> This does not automatically put the graph in as a named graph;
> ]]
> 
> Well, I wonder what the "name of a graph" is...
> It seems to be a URI a graph is given by the local system when read into the 
> aggregator.

rq23 does not say, one way of the other, whether the URI is where the graph as
read from, or it's a local identifier - only that the graph has a name as a URI.

Example: if an aggrgator caches graphs, it might well use where it read from.
But if it wants to keep old and new versions, it can't do that as they would
have the same name.

There are lots of choices here.


> 8.4
> [[
>  Each time a graph is read into the aggregator, it is given a URI by the 
> local system.
> ]]
> but, so it may not be the same URI the graph had BEFORE being aggregated,
> which means we cannot know the name of a named graph without asking (but 
> how?) !

Either: the application knows because it knows the service it is using (this is
normal - a database app knows the database).

Or ask:

SELECT ?g WHERE { GRAPH ?g { [] [] [] } }

gets the names.


> 
> It seems that a subgraph in the default graph can also have its name.

Yes.  Example:

FROM <a>
FROM NAMED <a>

which build a dataset with a named graph (<a>, G) and also uses G as the default
graph.


> The example in 8.1 implies this. But isn't  that the URL where the subgraph 
> was taken from?

For <http://> URLs , they should be read with GET (inc web caches etc).

If a system does not want to do web fetching, it wouydl give an error when the
query asked for fetching.

Should rq23 explicitly say <http://> implies GET?
Does any one have an example where it woudl nto be GETted in some way?

> 
> It puzzles me. Does a copy of a graph has the same URI as the original one?
> It seems to be No, then what we call "the name of a graph" is not given by 
> the local system,
> but it has been already given to the original graph

As above - it depends.  There seem to be different scenarios and rq23 is being
neutral.

> 
> If so, then why a graph incorporated by FROM clause cannot be called (or 
> named) by the URI
> in that clause?

It can by the construct:

FROM <a>
FROM NAMED <a>

> 
> And what is the motivation of distinguishing FROM and FROM NAMED?

FROM only related to the default graph
FROM NAMED only related to the named graphs

> 
> I remember FROM NAMED doesn't incorporate a graph to the default graph (but 
> where in rq23?),
> while FROM does so.

Yes.

> 
> But does it mean FROM has a side effect to the default graph?

I'm not sure it's a side effect.

FROM does not name the graph in the set of named graphs in the dataset.

> 
> Best,
> Yoshio
> fukushige.yoshio@jp.panasonic.com
> fuku@w3.org
> 

Summary:

FROM controls the default graph

   FROM <u> => a dataset has a default graph based on <u>

FROM NAMED controls the named graphs

   FROM NAMED <u> => a dataset has (<u>, G)  in teh named graphs of the dataset


If any specific text pointed you in one way or another that you find wrong,
please say so.

	Thanks,
	Andy

Received on Thursday, 2 June 2005 11:31:54 UTC