| [higgins-dev] more filter assertions or less digital subject |
|
In my hastily proposed IFilter interface, I forgot to consider that an IDigitalSubject has more than just attributes. It has:
- a type (String)
- a unique ID (String)
- attributes (IAttributes which themselves are type/value(s) pairs and metadatas (which are type/value(s) pairs))
- metadatas (which are type/value(s) pairs))
- relationships (which are type/IDigitalSubjectRef(s) pairs, where IDigitalSubjectRefs are contextRef/CUID pairs)
I've only addresses attributes so far. That is to say, IFilterAssertion should really be named IAttributeAssertion. Then, logically, I should add an ITypeAssertion, ICuidAssertion, IMetadataAssertion, and IRelationshipAssertion (note that some of these are similar enough to re-use the same interface).
Thinking about this made me remember some unfinished discussions though. These had to do with whether or not some of these items are actually attributes which happen to have a handy "short-cut" API. One example was the subject's CUID. We talked about setting aside a reserved attribute called something like higgins:cuid which would ultimately be in the range of xsd:string (this is why getUniqueID() returns a string today).
So that got me wondering if we need all those assertion interfaces or not.
The questions I guess boil down to this: Which (non-attribute) members of an IDigitalSubject are actually also represented as attributes? Type and CUID could easily be represented as attributes. So could relationships. Metadata could also be easily represented as attributes, but this has always caused contention among people who want a clean separation between the two.
Jim |