[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdAS Attribute data model

Personally, I would like to see metadata at the value level, even if that means some metadata is duplicated.  I'd like to see that metadata useable, preferably configurably, to match values for "sameness" for updates and the like as Marc mentioned.  Not just "source" but whatever is configured in the schema as the "matching" elements from the metadata for a value... plus other matching concepts such as those found in LDAP schema (matching rules).

I don't mind if we leave metadata at the attribute level as well (don't know the use cases) so long as it is not used for matching values.  From a consumer view, I'd like to see each attribute have one and only one incarnation with all values "contained" therein, rather than getting potentially n eyeColor attributes each with 1-n values as I think the current model yields.

Does that match your "another suggestion" below?  If so, +1.


>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 3/27/2007 5:35 PM >>>

It looks like now that people are implementing and using IdAS, they dislike an aspect of the model we defined at the Raleigh (I think) Face to Face meeting.

Prior to that meeting, my understanding was this:
A Digital Subject holds attributes, each distinguished from others held on that subject by attribute type, and each possibly having multiple values.
Resulting from the decision at that meeting, my understanding became:
A Digital Subject holds attributes, each distinguished from others held on that subject by attribute type and metadata, and each possibly having multiple values.
Our contrived example was that a subject (we called her Mary), had a blue eye color (as reported by one source), and a green eye color (as reported by another source).  "blue" and "green" were seen as attribute values.  "eyeColor" was seen as the attribute's type, and the notion of "source" was seen as metadata.  Thus, using IdAS interfaces the Subject had two IAttributes -- both with the same type (the type for "eyeColor"), and each with different metadata (one having source="source1", the other having source="source2"). (we had a better example, but I can't remember it right now)
Now, in order to update Mary's eye color which has the source of "source1", we must disambiguate it from the other eye color attribute.
In terms of the data model, this gave us the most flexibility.  Now, in terms of usable interfaces, it looks like we might want to re-think.  People dislike having to disambiguate among attributes by specifying the metadata of the attribute they're referring to.
An alternate suggestion was to pair the metadata with the values and not at the attribute level.  This was discussed at the F2F, but became unpopular due to the amount of duplicated metadata foreseen in instances of the data model.
Here's another suggestion (I don't remember if it was put forth at that same meeting or not):  Allow metadata both at the attribute and attribute value level.  Only one attribute of a given type is allowed on a Digital Subject.  Metadata common to all values of the attribute may be placed at the attribute level, while value-specific metadata is held at the value level.  This still causes some amount of "metadata duplication" among values, but is minimized.
Any other suggestions?