W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: TKS/Kowari named graph usage

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 08 Dec 2004 18:06:35 +0000
Message-ID: <41B742AB.4080400@hp.com>
To: Tom Adams <tom@tucanatech.com>
CC: DAWG list <public-rdf-dawg@w3.org>

Tom Adams wrote:
 > Hi all,
 >
 > Quick message on named graphs. We generally see the use of named graphs
 > for the following reasons:

Tom,

Thanks for the examples of named graph usage in TKS/Kowari.  Looks like you have 
examples of both trusted and untrusted graphs.  The technical question is 
whether there is a requirement for access to patterns that span (trusted) graphs 
that also would like source information available; then, the follow-up question 
of how convenient it is in the syntax.

Let me try to classify your examples:

> o Provenance - this model contains triples from here;

This one suggests the untrusted graph model is wanted.

> o Data ownership - my data lives here, yours there;

As part of the data management solution, would I be right in saying that the 
origin information is not needed by the user/appliction (where the application 
is not the tool doing the data management)?

If so, making the RDF look like one merged graph would seem to be what the 
application wants.

> o Security - only the following users can have access to this data;

This sounds like the creation of the dataset for the query based on who is 
issuing the query.  Once the user has been authorized, does it matter to the 
user / application where the data was?  That is, is the security usefully 
visible to the end application / user, or is it usually a matter of control by 
the information publisher.

> o General app-specific usage - all stuff that this user has touched 
> lives here;
 > o Separation of data - schema data lives here, instance data there.

These seem to be aspects of data management again.  It is useful to keep a 
separation so one part can be updated independently of other parts, even backed 
up differently, but does the application or user see this when querying?

> I see all this as being specific use cases of the more general need to 
> be able to split data across multiple containers (where these 
> containers may or may not share data).
> 
> We're also starting to see some more use cases coming up. For example, 
> a current customer and a prospect in the intel arena both want to be 
> able secure what they call ad-hoc graphs, which means creating a view 
> (a read-only graph) that is defined from the results of a query.
> 
> Named graphs in TKS/Kowari also have types, which correspond to the 
> underlying data store holding the information (these are our 
> resolvers). So for example we have a graph of type tucana:Model that is 
> our native store and a tucana:LuceneModel that is a graph backed by a 
> Lucene index [1].
> 
> Please hassle me some more and I'll send more information and hassle 
> more customers!

Consider this a polite hassle.  I'm trying to get a sense of what is a necessary 
requirement and what is a useful feature; also what is a generally agree 
approach and what is currently more speculative.

	Andy


> Cheers,
> Tom
> 
> [1] http://www.kowari.org/176.htm
> 
Received on Wednesday, 8 December 2004 18:07:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT