Named Containers / was: Re: UC&R ready for review

Alberto Reggiori wrote:
> 
> (replying as the original author of the "identity management" use case)
> 
> On Oct 4, 2004, at 10:05 PM, Pat Hayes wrote:
> 
> 
>>>  RDF Data Access Use Cases and Requirements
>>>  Revision: 1.138, Date: 2004/10/01 19:56:52
>>>  http://www.w3.org/2001/sw/DataAccess/UseCases
>>>
>>>is ready for review for publication.
>>>
>>>Kendall
>>
>>2.15 Mr X has two personae, why does he need three PPDs?
> 
> 
> in the scenario I had in mind (the Web?),  he might have several 
> separated PPDs handed around (one sitting on his home directory on the 
> laptop /Users/MisterX/foaf.rdf, one on a Web site at work, one on his 
> palm/iPod, one on a 3rd part server annotated by somebody else and so 
> on) - perhaps not all synchronized (merged) together and having 
> different trust levels - and overlaying to describe his two persona(s) 
> (characters).
> 
> my whole point with the "identity management" UC was to try motivate 
> the need of named-graphs (named containers) as bNodes and not simply 
> URIs i.e. here is my profile persona1.rdf, here is my profile 
> persona2.rdf  VS. here is my FOAF profile source about my persona(s). 
> In a certain sense have the possibility to refer to the whole 
> 'collection of named containers' about MisterX FOAF information 
> (instead of each separated conatiner) and distinguish each of them at 
> query time, as outlined in Andy's proposal
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0581.html
> 
> is there any reason why a named-graph can not be a bNode and 
> referenced-by-description?

Alberto,

The proposal is trying to find common ground between all the approaches I have 
found.  It can't be compatible with all of them.   The important thing at the 
moment is question of whether the approach is acceptable.  It does provide some 
structure; in some places it does not say how an implementation has to do things 
because different impls may choose to do things differently. In particular, it 
changes the use of bNodes in SOURCE and dc:source in your and Steve's test cases 
into a single, different SOURCE operator so the relationship isn't fixed and 
there are no issues about returning the ?snode variable.

There are some issues that arise with bNodes such as which graph they are in.  I 
noted that "named graphs" does not allow bNodes.  When returning query results 
in a SELECT, bNodes don't make a lot sense but URIs do.  Hence, restricting to 
URIs so see if the overall approach is workable in the working group.

The proposal does not enforce a single way that a URI is associated with a graph 
- maybe it should.  What it does do is to say "SOURCE <uri>" and leaves it to 
implementations to create the association of URI to the graph.  The test cases I 
produced have graphs in documents and its the URI of the document (c.f. 
log:semantics).

I showed how I thought it is done for RDFStore, finding the bNode used for the 
graph, so recovering the bNode seems possible.


An observation : If a merge of things is meaningful/valuable on the web, give it 
a URI.  The fact it is kept in 3 separate files and merged to create the overall 
"my FOAF profile source about my persona(s)" doesn't stop that having a URI.  As 
its a sigtnificant thing published it should have a URI. The your "here is" can 
be HTTP GET.

	Andy

> 
> Yours
> 
> Alberto
> 
>

Received on Tuesday, 5 October 2004 08:58:17 UTC