- From: Richard Newman <rnewman@twinql.com>
- Date: Tue, 2 Sep 2008 19:41:12 -0700
- To: Brian Manley <brian.manley@gmail.com>
- Cc: Semantic Web at W3C <semantic-web@w3.org>
> In the DBMS world, things like "label security" seem to be > implemented primarily by automagically modifying the WHERE clause to > filter on a column that denotes ownership. > Alternately, I could just provide another triple for each resource > in my store and only restrict at the resource level rather than the > triple level. For example . If you think about it, these two things are the same: modifying the data directly to include access control information. (Not quite the same as adding metadata to the graph, which is an annotation.) The results are also the same: you have to alter your query correspondingly. The difference comes in the complexity of the alteration. SQL is happy to oblige when you add another column; just one more WHERE clause. If you store your addition explicitly in RDF, your SPARQL queries get much more complex, because there is no provision for introducing new abstractions (and you have choices to make: when you have a triple between two resources, which resource do you look at for access control -- s, o, or both?). If you store your new info "behind the scenes" -- extending your implementation -- your queries remain simple, but SPARQL doesn't know the new info exists... so you need another channel for communicating your access control credentials, and you can't write SPARQL queries that interrogate those new statements. It's a tradeoff, but adding info to your back-end DB is the way I'd choose out of those two approaches. Interesting problem to discuss! -R
Received on Wednesday, 3 September 2008 02:41:50 UTC