Daniel,
The schema (higgins.owl) can define the count
of values of attribute (using cardinality restrictions), not the
count of attributes. There is no any equivalent of IAttribute interface
in the current schema (except of Attribute class, which was added to
hold metadata of attribute and does not have any relations to values of
attribute). We just supposed, that for DigitalSubject there can be 0 or 1
instance of IAttribute with appropriate type, but it was
only an assumption for IdAS interfaces level, not for HOWL
schema. Now, if you add an attribute, but does not add any value
to this attribute and store the context, nothing happens with real data. If
you get this DigitalSubject next time, it will not contain an
attribute you added before. So, because IAttribute is an
abstraction and only aggregates values, there is some reason to
suppose that DigitalSubject has exactly one instance of attrubute
regardless of presence/absence of its values/metadata.
Thanks, Sergey Lyakhov
----- Original Message -----
Sent: Thursday, January 10, 2008 4:30
PM
Subject: Re: [higgins-dev] Higgins data
model for attribute values
The schema for a particular type of digital subject may state that an
attribute is optional, in which case you cannot assume that there is always an
instance of that attribute on a particular instance of a digital
subject. For that reason I don't think we can remove addAttribute( URI
attrID) from the IHasAttributes interface - optional attributes must be
explicitly added. In addition, some attributes may be not readable
(such as password). Therefore, when you get a digital subject and
enumerate the attributes, you may not see some attributes. But you still
need a way to set such attributes.
Daniel Sanders
>>> "Sergey Lyakhov"
<slyakhov@xxxxxxxxxxxxxx> 1/10/2008 4:57 AM >>>
IAttribute interface is an abstraction which only
agregates values. When we call IHasAttributes.addAttribute(URI attrID)
method, there is nothing happens with attribute owner (no data is
added/changed). So, it will be more convenient to suppose that DigitalSubject
(ComplexValue, ComplexMetadata) always have an instance of attribute
if its type is defined by schema. In this case we can remove
addAttribute(URI attrID) method from IHasAttributes interface.
Thanks, Sergey Lyakhov
----- 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
_______________________________________________ higgins-dev mailing
list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|