[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Higgins data model for attribute values
|
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
