[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