|
It seems to me like we could define a way to express access control policy without defining things like people, groups, org's, etc. Looking at it from a projected narrative might show what I'm talking about:
At some point, I believe we will say: "it's good that we can make the subject of a policy statement be a group, and that there's a special semantic tied to that kind of relationship (somehow we know that the subject is *really* all the members of that group), but... now we need the subject to be this *other* thing with it's own semantics, and then this other thing and then this other thing..." That exercise will show that the special semantics of pointing at special subjects can't always be "hard-coded" into the higgins data model.. So we'll invent a generic way of defining new kinds or policy to subject relationships that can be added at any time which don't cause a revision of the higgins data model. At that point, we can (and should) unwind the whole stack of existing "special policy to subject relationship" and re-represent them in the new generic way. So at the end of the day, we'll realize that we never actually needed to add person, group, org, etc to the core data model.
This is partly why I suggested we allow a policy to subject pointer to allow specialization. That way, the semantics of the relationship are held with the relationship -- not with the subject. Also, these relationships can be defined anywhere -- they don't need to be defined in the core data model (at least to my view at the moment)
Jim
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 07/10/08 9:33 AM >>>
All true.
We’re trying to put as little as possible in HOWL, however the new access control policy work needs notions of Groups or Organizations (e.g. for roles) and it seems necessary to be able to distinguish between generic objects (Entities) and kind of agents like Group, Organization and Person. New kinds of Attributes like memberOf (and its inverse member) and partOf (and part) are also needed to cover the use cases we’ve identified. For the access control stuff to work interoperably across Contexts there needs to be agreement on the primitives.
-Paul
On 7/10/08 1:47 AM, "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> wrote:
Good point, and maybe worth discussing on the call tomorrow (if there’s time). It strikes me that, like almost all things in vocabulary, you can never force semantic bindings. If someone wants to derive their own notion of Person from Entity, you can’t stop them. So it’s only if they want shared semantics that they would be incented to derive from Higgins Person.
=Drummond
I was thinking it meant that too until I read:
Maybe that's not actually saying anything more than what you just said.
Still isn't it overly prescriptive to say that everyone's notion of a person and group must adhere to the higgins notion (or a subtype thereof)?
Jim, I am not the HOWL expert at all, but my understanding of what Paul is saying is that a CP only need to support (i.e., use or extend) the HOWL notion of Person or Group if it needs to represent people or groups. So a CP that only exposes hardware or software resources might only need Entities and Attributes.
Wednesday, July 09, 2008 9:56 PM
Re: [higgins-dev] Questions wrt HOWL 1.1
Does anyone else find this a bit overbearing? Why do we want to prescribe that all CP's support our notion of a Person and Group? Shouldn't we have different profiles for different kinds of CPs?
If I deploy a CP that only exposes hardware resource, or software resources, why should it need to support a Person or Group?
Hi,
I have been going through HOWL 1.1 and here are some questions wrt the
same:
HOWL 1.1 defines new OWL classes like Person, Group etc. Is it necessary
that context providers who conform to HOWL must derive their
implementations of Persons and Groups from the HOWL 1.1 Person and
Group?
>> Yes they should.
And if so, does it mean that one could query for persons using
http://www.eclipse.org/higgins/ontologies/2008/6/higgins#Person across
all context providers?
>>Yes.
HOWL 1.1 does not seem to have the Attribute class that was present in
HOWL 1.0.
>> Perhaps you are referring to the higgins:attribute property that was present in HOWL 1.0 and was removed in HOWL 1.1. If so, this was done to allow developers to reuse existing properties from other (non-Higgins) OWL, and RDFS vocabularies. The higgins:attribute was used as the abstract super-property of all higgins-defined properties—but it was never used directly.
As I understood the CDM, all entities in the context must be
subClassOf &higgins;#Entity and all attributes must be a subPropertyOf
&higgins;#Attribute. Does this still hold?
>> The first half of what you say holds: all developer-defined Entities must subclass Entity (or one of its subclasses (e.g Agent, Person, Group or Organization and soon Policy). The second part is no longer true —there’s now nothing special about a higgins property (e.g. higgins:correation) vs. a property from some other namespace (e.g. foaf:knows).
Thanks,
Best regards,
Rajalakshmi Iyer
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
