Re: TKS/Kowari named graph usage

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 UTC