[higgins-dev] Constraining a Digital Subject's attributes

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

When getting a DigitalSubject from a Context, I think the caller needs a
way to (optionally) constrain the attributes/relationships held on the
DigitalSubject. Maybe "constrain" gives the wrong impression. The caller
needs to be able to provide a list of attributes it intends to consume.

Given that some context providers will use network protocols to
gather/produce DigitalSubjects within a context, and given that the
amount/size of all possible attributes on a DigitalSubject may be very
large, the possibility of causing undue performance problems exists
unless there is the ability of the caller to specify a list of
attributes/relationships to be associated with a DigitalSubject being
interrogated.

Here's an example: 

A context provider uses LDAP as its store. A caller asks for a
DigitalSubject by name. The underlying context provider performs the
LDAP search operation to locate and read the named object, and return a
DigitalSubject using the information returned.

Now, the provider didn't know which attributes would ultimately be
read, so it either: a) read all attributes from the LDAP server, or b)
read none, or c) read a few configured ones.

In terms of avoiding further network traffic, the best bet is (a). But
in this case, the provider may have performed a very expensive operation
as LDAP objects may be populated with large numbers of attributes of
large size. OTOH, (b) may, and  (c) will result in the provider sending
further protocol requests to gather attributes as they are being read
from the DigitalSubject.

Does anyone see problems in adding a mechanism to instruct the context
provider which attributes will be read?

Jim