- From: Phil Dawes <pdawes@users.sf.net>
- Date: Sat, 11 Sep 2004 06:12:09 +0000
- To: kendall@monkeyfist.com
- Cc: Damian Steer <damian.steer@hp.com>, Chris Bizer <chris@bizer.de>, public-rdf-dawg-comments@w3.org, "<www-rdf-interest@w3.org>" <www-rdf-interest@w3.org>
Kendall Clark writes: > On Fri, Sep 10, 2004 at 10:37:42AM +0100, Damian Steer wrote: > > > A quick follow up on this: I think it might be useful if people who > > need the ability to track the source(s) of a statement could provide > > use cases for dawg <mailto:public-rdf-dawg-comments@w3.org>. I know > > Phil Dawes has a use case, mentioned at foaf galway. > > > > DAWG people: Is this a good idea? > > Yes. > > Best, > Kendall Clark (speaking as DAWG use cases document editor) > Hi Kendall, Hi Damian, My graph-based usecases are pretty simple (and I think similar usecases have already been discussed on the dawg list): Usecase 1: Tracking provenance and graph information. We have an aggregate store at work, which merges information from lots of sources (ldap, inventory databases and monitoring systems). We use my veudas web rdf editor to view and edit this information. The store gets refreshed every night, purging and re-asserting the graphs from their sources. In addition to these read-only graphs, there are also 'editable' graphs which don't get purged by the refresh. The veudas editor needs to track provenance information from the remote aggregate store in order to display which triples are read-only and which can be edited (it greys out read-only triples in the editor). Usecase 2: Using graph matching for security One of the sources for the aggregate store is the company global ldap directory, which contains people and group information used for access control. When using the aggregate store to access security information, the app needs to ensure that the information has come from the right source. Without graph-matching, any of the other sources could theoretically add a (joeBloggs memberof superusergroup) triple to the mix and subvert the security. I've put some more dawg usecase related thoughts in my blog: http://www.phildawes.net/blog/ Recently I've been thinking about how to present results to the client in a way that is useful to its needs - particularly with respect to 'logical' resources vs the (potentually many) URIs they can have. I'm not sure I'd expect any of these ideas to get into DAWG (at least not in this phase), but somebody might find them interesting. Hope this is useful, Cheers, Phil
Received on Saturday, 11 September 2004 14:59:51 UTC