Re: Triple Access Control

Hi bergi,

On 9/21/2011 1:22 AM, bergi wrote:
> Am 15.09.2011 12:56, schrieb Bob Ferris:
>> 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)
>
> It's my server, so I can configure that.
>
>> - you should include references for accessing alternative serialisations
>> of your vocabulary, e.g., in Turtle, RDF/XML, ...
>
> It's already there [1]. I had to prepare that for specgen.

Yes, I know. However, with "references" I had visible links from [1] to 
[2] and [3] in mind ;)

>
>> - you should include references to downloadable files of your outlined
>> example (e.g. in different serialisations)
>
> I've already created a template for specgen6. It's not finished now, but
> this version will include links to the examples.

Cool! (Btw, SpecGen6 is now located at GitHub as well, see [4] ;) )

>
>> - it might be good to include a further example that makes use of the
>> tac:graph property
>
> Good idea, but that will take some time. I'm very busy at the moment.

Okay, no problem. Take your time.

>
>>
>> 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
>
> Also I wasn't sure if I should add it or not. I just wanted some
> documentation for the properties. But it may be the best to have this
> documentation in the TAC ontology.

Yep, I think that providing a definition for these terms in the TAC 
specification might be enough.

>
>> - 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)).
>
> I didn't had time to read all that stuff. But a single property like
> tac:statement, would be fine, or?

Yep, I think that would be enough.

>
>>
>> Cheers,
>>
>>
>> Bo
>>
>>
>> PS: It might be interesting to see an example that utilises the TAC
>> Vocabulary and a combined role-group-modelling
>
> It's on the todo list...

Cool!

Cheers,


Bo


[1] http://ns.bergnet.org/tac/0.1/triple-access-control.html
[2] http://ns.bergnet.org/tac/0.1/triple-access-control.rdf
[3] http://ns.bergnet.org/tac/0.1/triple-access-control.ttl
[4] https://github.com/zazi/specgen

Received on Wednesday, 21 September 2011 10:09:02 UTC