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