Re: Triple Access Control

Hi bergi,

after I've reviewed your proposal a bit deeper, here are my remarks:

1. Vocabulary/Ontology specification documentation:
- it might be good to introduce a PURL (e.g. purl.org) for your 
vocabulary, which also do content negotiation (let me know if you'll 
need help on this)
- you should include references for accessing alternative serialisations 
of your vocabulary, e.g., in Turtle, RDF/XML, ...
- you should include references to downloadable files of your outlined 
example (e.g. in different serialisations)
- it might be good to include a further example that makes use of the 
tac:graph property

2. The TAC Vocabulary:
- I really like the filter approach with setting a subject, predicate 
and object as needed
- I would remove the dependency to the RDF Reification Vocabulary from 
tac:subject, tac:predicate and tac:object properties, since the sub 
property relation do not really add any value to your intended modelling
- the tac:graph property is really fine, however, what about single 
statements - I know this is still a problem in general and especially 
the RDF WG Graph Task Force [1] tries to enlight this topic a bit. 
However, in general RDF Graphs that consist of one statement are mess, 
if they exist where they do not really have to existing. That's why, I 
would vote one more time for statement identifier (see [2]). They could 
also be utilized to cover the circles use case as well, i.e., the 
circles content will be represented with a RDF Graph enclosure and due 
to the fact that each statement can be identified via a statement 
identifier, it can be utilised in multiple graphs. What do you think 
about this? (Albeit, one could utilise RDF Graphs here as well to 
enclose a full resource-description (e.g. a post)).

Cheers,


Bo


PS: It might be interesting to see an example that utilises the TAC 
Vocabulary and a combined role-group-modelling


[1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC
[2] 
http://lists.w3.org/Archives/Public/public-rdf-comments/2011Jan/0001.html
[3] 
http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-hyperedges---find-user-roles-in-groups

On 09/15/2011 08:20 AM, Bob Ferris wrote:
> Hi bergi,
>
> On 09/15/2011 12:29 AM, bergi wrote:
>> Am 13.09.2011 21:32, schrieb Melvin Carvalho:
>>>>
>>>> What do you think about my proposal? Somebody has a different approach?
>>>
>>> Another possible approach:
>>>
>>> use owl : sameAs
>>>
>>> If the agent has access return some triples, if not return FORBIDDEN
>>
>> How would you handle complex scenarios like G+ in RDF?
>>
>> One approach could be a resource per circle. But that would mean you
>> have to duplicate some of your data.
>
> You can utilise a named-graph-approach for circle that is able to handle
> (identifiable) triples* over multiple graphs**. In my modelling approach
> described at [1] I tried to cover this issue.
>
>>
>> It would be possible to spread your triples in a way that there are no
>> duplicates, but wouldn't that be more complicated to handle than
>> describing the rules using the ontology I proposed?
>>
>> And how do you handle write access? If the data doesn't exist there is
>> no resource to point to.
>>
>
> You can deploy an access-controlled write access direct on the URI/URL
> where do you like to create the resource or on a so called "parent
> resource" that is related to the resource you would like to create (see
> HTTPbis draft for a definition of this term). Both approaches should be
> RESTful.
>
>> Maybe there is a simple solution to the problems I've described, but
>> currently I mainly see disadvantages.
>>
>
> Well this a rather complex problem. It might still be the simplest
> solution ;)
>
> Cheers,
>
>
> Bo
>
>
> *) statement identifier
> **) this is currently not covered by the existing Named Graph
> specification, see [2]
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-comments/2011Jan/0001.html

Received on Thursday, 15 September 2011 10:57:27 UTC