W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2002

Re: Contexts (spinoff from copy and wrap rdf statements)

From: Seth Russell <seth@robustai.net>
Date: Mon, 25 Nov 2002 10:04:32 -0800
Message-ID: <3DE26630.9030008@robustai.net>
To: David Menendez <zednenem@psualum.com>
CC: rdfig <www-rdf-interest@w3.org>

David Menendez wrote:

> At 11:15 AM -0800 2002-11-24, Seth Russell wrote:
>
>> I suppose that would work as long as we agree that the uri [of the 
>> document] identifies the graph and not the document.  Thing is we 
>> have text in the Concepts document [1]  that conflicts with your 
>> interpertation:
>>        "So when someurl#frag is used in an RDF document,
>>         someurl is presumed to designate an RDF document."
>> The whole point is agreeing on a standard, and bucking the WG is not 
>> going to help us there.   I dont think using the frag #ThisGraph 
>> conflicts with any WG text.  It would be nice if the WG saw the need 
>> to refer to the abstract graph with a URI and gave us a standard 
>> syntax to do that.  But don't hold your breath.
>
>
> On further consideration, what I said before doesn't really match what 
> I think about this, so let me try again.
>
> We have a URI, <http://example.org/c.rdf>, which identifies a 
> resource, R. (I'm picking arbitrary names right now. In terms of 
> RDF-MT, R = I(<http://example.org/c.rdf>).) The result of 
> dereferencing the URI is a string of bits, B, which are a 
> representation of R. Assuming B is appropriately formatted, we can 
> derive a graph, G, by parsing it.
>
> You, then, are claiming:
> 1. G needs a separate identifier from R
> 2. This identifier should be <http://example.org/c.rdf#ThisGraph>
>
> I agree with point 1, but I disagree with point 2. I think G should be 
> related to R by an explicit triple, rather than a naming convention.

I totally agree.  Keying off of the naming convention breaks the opaque 
URI edict.  I still think the naming convention is a good convention, 
but we should have a class or a property that relates the rdf document 
(or any representation of it) to the graph.   Perhaps something like:

<http://example.org/c.rdf>  
    ex:encodesGraph   <http://example.org/c.rdf#ThisGraph>.

<http://example.org/c.rdf#ThisGraph>  
    rdf:type ex:Graph;
    dc:source <http://example.org/c.rdf>. 

> One possibility:
>
> { :Stassi a :Cat; :belongsTo :Me.  }
>   dc:source <http://example.org/c.rdf>;
>   dcq:issued "2002-11-22t10:00z";
>   eg:encodedAs xml"<rdf:RDF ... </rdf:RDF>";
>   eg:signature "...".
>
> Alternately, you could have an explicit node for B.
>
> { :Stassi a :Cat; :belongsTo :Me. } eg:derivedFrom [
>   a eg:Representation;
>   dc:source <http://example.org/c.rdf>;
>   dcq:issued "2002-11-22t10:00z";
>   dc:format "application/rdf+xml";
>   dc:language "en";
>   eg:encodedAsText "<rdf:RDF ... </rdf:RDF>";
> ].

I'm ok with both of thoses; but we don't end up with a URI for the 
graph.   I have a use case that almost requires a URI for the Graph. 
 Suppose I have a Graph that is collectively authored.  We want anyone 
form whatever domain to be able to write a RDF document and assert it to 
the same Graph.  So I would like to be able to do something like:

In domain catLover.org  we find a rdf file that says:

{
[a :Cat;
        :belongsTo [ foaf:mbox <mailto:piggy@giggy.poo> ]
        : called "Stassie"]
}
  assertedTo <http://example.org/context/cats#ThisGraph>.

In domain catsAreUs.com we find a rdf file that says:

 {
[a :Cat;
    :belongsTo [ foaf:mbox <mailto:twiggy@skaggy.doo> ]
    :called "Tabby"] 
}
   assertedTo <http://example.org/context/cats#ThisGraph>.

Anyone who discovers this context can make an interesting graph about 
cats and their owners.   Now I suppose you could come up with a way to 
do that and have the  context represented by a bNode.   But don't you 
think it will be more convient to have an explicit name for the context?  

Seth Russell
Received on Monday, 25 November 2002 13:05:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:57 GMT