Re: [Fwd: Some questions about Named Graphs]

Hi Yuzhong,

my replies in line, I guess the others will chip in.

> From: Yuzhong Qu <>
> To: <>, <>
> Subject: Some questions about Named Graphs
> Date: Mon, 28 Jun 2004 18:12:09 +0800
> Dear Jeremy and Christian,
> I found the paper entitled "Named Graphs, Provenance and Trust" is
> terrific good.

Thanks again

> Some questions arised when I read the section 2 "Abstract Syntax and
> Semantics" of this paper.
> 1. 5-tuple <N,V,U,B,L> where: U is a "set" of URIrefs; L is a "set" of
> literals (both plain and typed); B is a "set" of blank nodes; ......;N
> is a "set" of pairs forming a partial function from U to V  U  V .
>    Are they finite sets? I guess they should be.

I haven't thought. With RDF abstract syntax we tried to avoid specifying
finiteness - it seems limiting in some ways.
I guess I would make a finiteness assumption only when I needed it. The
named graphs paper is currently so high-level that finiteness doesn't
seem necessary.

>   As to "N is a set of pairs forming a partial function from U to V  U
>  V", why not a partial function from U to P(V  U  V)? (The power set
> of ...) because you use "partial function" instead of "partial mapping".

thank you, that was a bug. I will work that into the next version.

> 2. For ng, ng' belonging N with ng != ng'then the blank nodes used in
> triples from rdfgraph(ng) are all distinct from those used in triples
> from rdfgraph(ng'), i.e. blank nodes cannot be shared between different
> graphs named in N.
> What's the criteria to test ng = ng'? I guess it depends on the equality
> of the first elements of the two pairs, i.e. whether or not name(ng) =
> name(ng'), then it depends on the equality of URIrefs?

This looks like an editing problem. In earlier versions (maybe
retrievable from www-archive), we allowed multiple names for a single
graph. In the current version I am not sure whether we do or not.

I think I need to look back over the history.

It seems to me that we could allow multiple names for one-and-the-same
graph by changing the test to
  rdfgraph(ng) != rdfgraph(ng') where != is the identity inequality not
the isomorphism one.

> In addition, why you must require "the blank nodes used in triples from
> rdfgraph(ng) are all distinct from those used in triples from
> rdfgraph(ng')"?  I mean that the above requirement (or assumption) seems
> redundant. Even worse, in some cases, two blank nodes within two
> different graphs may be equal due to the fact that they have the same
> value for an inverse-functional dataProperty (in OWL), or the two blank
> nodes are equal to each other within some context.

No, that's your misunderstanding I think.
So, two blank nodes in two graphs may denote the same thing, that's OK.
What we were trying to ensure is that there were not problems at the
semantic level. We took a conservative line of not extending the RDF
semantics except where unavoidable. So the blank node condition is
simply meant to reflect that two graphs in the abstract syntax for named
graphs look and behave like two separate graphs in the RDF abstract
syntax. The RDF semantics does not really cover the case when you have
two RDF graphs sharing a blank node; it really isn't clear what that is
meant to mean, so we avoid it by this restriction.

> 3. Can a blank node denote a named graph (or graph)?


>    If it can, how about the corresponding syntax?

No syntax is provided for saying which graph, but for example

eg:a {
_:b rdf:type rdfg:Graph
_:b rdfg:subGraphOf eg:a

makes _:b a graph and it must be one of the four subgraphs of eg:a.

This restriction is not in the earlier TriX paper, but when we came to
look at the semantics we felt the more conservative line introduced
fewer questions.

> 4. As to the Namespace and RDF Schema:
> xmlns:rdfg=""
>    The class "rdfg:Graph" is to represent the concept of named graph,
> graph, or other thing?

named graph

>    I guess it's about named graph, then why not use the word "NamedGraph"?

I prefer graph, for political reasons. It emphasises the continuity from
RDF. I don't now about anyone else.

> Thanks for your concern!
> Yuzhong Qu

Received on Monday, 28 June 2004 10:14:23 UTC