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