Re: [higgins-dev] Questions wrt HOWL 1.1

[Paul Trevithick <paul@xxxxxxxxxxxxxxxxx>]

Title: Re: [higgins-dev] Questions wrt HOWL 1.1

Jim,

Where I think I differ with your view that there really are any downsides of “hard-coding,” as you put it, a few everyday concepts like Group, etc. into the model. I don’t see the downside since developers are always free to add whatever semantics they want. They can even ignore the “hard-coded” Higgins concepts of Group, Person, Agent and Organization if they like (at the cost of some interoperability). Or more hopefully and more likely, they can specialize these classes and define their subclasses to mean whatever they like. I don’t see how the higgins-defined classes tie their hands at all, but I do think they add power to the higgins data model and increase interoperability. 

Let’s look at higgins:Group from this point of view. Here is its definition in HOWL 1.1.102 (in N3):

> higgins:Group
>       a  owl:Class ;
>       rdfs:comment "A class of Agents."@en ;
>       rdfs:label "Group"@en ;
>       rdfs:subClassOf higgins:Agent .

And here’s all an Agent is defined to be:

> higgins:Agent
>       a  owl:Class ;
>       rdfs:comment "An agent (eg. person, group, software or physical artifact)."@en ;
>       rdfs:label "Agent"@en ;
>       rdfs:subClassOf higgins:Entity .
All we’re doing by introducing this vocabulary term “Group” is to provide a common term for whatever kind of set the developer would like to define. 

I emulated the Agent, Group, Organization, Person terms from FOAF in part to have compatibility with it, and in part to learn from their (vast) experience. FOAF is by far the most successful application of RDF ever created. There are millions of FOAF files out there. Although I share your desire for restraint in HOWL and still today HOWL (unlike FOAF) still has NO concrete attribute types . In fact FOAF is mostly about concrete attribute types—things like email address, blog, who your friends are, etc. I think it is a good idea for the Higgins (identity) project to have at least the terms of Person, Group, Agent and Organization defined—even as of the specifics are entirely left to context provider developers as it is today.

If we don’t have an agreement on the term Group. Then we won’t even know what one developer defines as a “Department” and another defines as a “F500 Company” are at least notions of sets of Agents/Entities. That minimum level of common understanding/interop is what I’m looking for. 

But let me get back to the “subject” attribute sub-typing on AccessControl Policy entities... I agree with you that this a great “extension point.” There’s nothing to prevent developers from doing this. Again, they’ll have to define their own semantics and their own implementation, etc. so nothing will be interoperable, but it is possible.

Lastly, one really cool thing I realized working on the access control use cases recently was that we can have the “subject” or the “operation” (resource-pointing) links point to a Class (as opposed to an instance). And since the developer can define what this Class means (e.g. what attributes must be present, etc.) we have the ability today (given proper inferencing by context provider implementations) to allow the “subject” or the “resource” of a policy object to arbitrarily define a set of Entities to which it applies. 

I’ll stop here. I hope something in this rambling note is related to the points you made in your email, but if I missed entirely, let’s discuss on the phone next week or on the dev call on Thursday.

Cheers,
-Paul

On 7/12/08 7:26 PM, "Jim Sermersheim" <jimse@xxxxxxxxxx> wrote:

 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
        
 


           

         


 

---

 

         


 From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, July 09, 2008 10:29 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] Questions wrt HOWL 1.1
        
 



 
 
 



 I was thinking it meant that too until I read:        
 



 
 
 

 

 
 
 
 


 >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.        
 



 
 
 

 

 
 
 
 


 
 
 



 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)?        
 



 
 
 

 

 
 
 
 


 
 
 >>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 07/09/08 11:11 PM >>>
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


 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.
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


  
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


 =Drummond
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


  
        
 


           

         


 

---

 

         


 
 
 

 

 
 
 
 


 From:
       
 

 

 
 
 
 


 higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
        
 

 

 
 
 
 


 On Behalf Of
       
 

 

 
 
 
 


 Jim Sermersheim
        
 

 

 
 
 
 


 Sent:
       
 

 

 
 
 
 


 Wednesday, July 09, 2008 9:56 PM
        
 

 

 
 
 
 


 To:
       
 

 

 
 
 
 


 higgins-dev
        
 

 

 
 
 
 


 Subject:
       
 

 

 
 
 
 


 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?
        
 

 

 
 
 
 


 
 
 >>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 07/07/08 8:17 PM >>>
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


 Hi Rajalakshmi,

See inline below...

On 7/7/08 1:54 AM, "Rajalakshmi S Iyer" <iyer_rajalakshmi@xxxxxxxxxx> wrote:
        
 

 

 
 
 
 


 
 
 

 

 
 
 
 


 
 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