----- Original Message -----
Sent: Tuesday, January 08, 2008 9:29 PM
Subject: Re: [higgins-dev] Higgins data model for attribute values
The better policy statement to use below would be: Allow Operation X on Resource Y if Group is present and not in Test group.
That aside, it does seem like these kinds of semantics, when we talk about them, become very specific to the attribute or application consuming the attribute.
Daniel suggested in person that we allow valueless attributes, and we state that the semantic difference between valueless attributes and non-present attributes is application-defined.
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 01/08/08 10:23 AM >>>
higgins-dev-bounces@xxxxxxxxxxx wrote on 01/08/2008 12:04:39 PM:
> We would have to make some kind of statement to that effect -- that
> a present attribute with zero values means that it is known that the
> object explicitly has none of that. So, a present attribute
> hairColor with zero values would mean we know the person is
> hairless, thus has an absence of hair color. I wonder if the
> semantic meaning changes with each attribute? A present attribute
> of age with no values means the person is dead or unborn?
I am offended by your baldness example.
> My memory is slowly returning to previous discussions now... We
> once came up with a completely different semantic. A present value
> of password with no value meant that we know the user has a
> password, and we're willing to produce an attribute with no value so
> that you may attempt to modify the password, but we're not going to
> reveal the password value to you. I suppose that could be handled
> in other way (that attribute could have a value, but an exception is
> thrown when one attempts to access it).
>
> In the face of access control, I wonder how meaningful any of these
> statements really are. Whether or not I can see an attribute on a
> subject, or whether or not I can see any values only means I can't
> see that data -- this could be due to access control, other policy,
> or an actual absence of data. If consumers need to differentiate,
> then we probably need to invent some specific exceptions to throw
> under various circumstances. Of course, then people will ask for a
> "don't disclose on error" kind of setting which will prevent the CP
> from throwing such exceptions, and the consumer will be right back
> in the same boat.
For access control. In case where:,
a) <Groups/>
or)
b) <Groups><Group>Test</Group></Groups>
or
c) no Groups attribute
and Policy is Allow Operation X on Resource Y if not in Test group.
I think "a" is clearly allowed, "b" is clearly disallowed, and "c" is not
clear.
>
> >>> Greg Byrd <gbyrd@xxxxxxxx> 01/08/08 9:32 AM >>>
> One point that Mike's bringing up (I think) is the difference
> between not having an attribute, and having an attribute without a
> value. In the latter case, there's a definite statement that we
> have no knowledge of this particular attribute. (If, for example,
> we know that a person has no driver's license.) If the attribute is
> missing, we can't know whether it's because there is no such
> attribute for this subject, or whether we just don't know anything about
it.
>
> In OWL, I think you'd have to have an explicit value that means
> "unknown", because you have to have a value associated with a
> property. This may or may not be represented in the same way in the
> IdAS model.
>
> ...Greg
>
>
>
>
> Michael McIntosh wrote:
>
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 01/04/2008 09:19:47 PM:
>
>
>
>
>
>
>
>
>
> Before addressing bug #190594, I need to know more about what the
>
>
> Higgins data model allows in an attribute's instance data.
>
>
>
>
> In IdAS, my understanding is that a Digital Subject may have 0..1
>
>
> occurrence of a particular Attribute, and that an Attribute may have
>
>
> 1..N occurrences of a particular type of Value.
>
>
>
>
>
>
>
>
> In the case of an Attribute X, I would like to better understand the
>
>
> semantic intended by the difference between the two cases where:
>
>
> a) there is 0 occurence of X,,
>
>
> b) there is 1 occurence of X with 0 values.
>
>
> Is there a difference? What is it?
>
>
>
>
> If this model changed to allow 0..N occurence of an Attribute, with 1
>
>
> occurence of Value for each Attribute, what would be the difference?
>
>
>
>
> If this model changed to allow 1 occurence of an Attribute, with 0..N
>
>
> occurence of Value for each Attribute, what would be the difference?
>
>
>
>
>
>
>
> It's my understanding that each of an Attribute's values must be of?
>
>
> the same data type, but that restriction isn't obvious to me in the?
>
>
> Higgins OWL, and in fact, the opposite is reflected in the IdAS
>
>
> APIs. In IdAS, one can state the data type of each value they add
>
>
> to an attribute.
>
>
>
>
> So, we need to agree on the Higgins data model regarding the types
>
>
> of attribute values. Should the Higgins data model dictate that
>
>
> they all be of the same type, or should it allow their types to be mixed?
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
> higgins-dev mailing list
>
>
> higgins-dev@xxxxxxxxxxx
>
>
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
> higgins-dev mailing list
>
>
> higgins-dev@xxxxxxxxxxx
>
>
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
