| RE: [higgins-dev] IdAS Attribute data model |
|
Jim, Some background
on this metadata problem… Following your example,
what I had wanted to do originally, i.e. last year, was attach to the entire statement “mary has eye color
of green” the metadata “as claimed by the RMV”. But what I ended
up proposing in the Here’s how
it works in practice. Mary’s
eyeColor attribute is represented by (i) an instance we’ll call “attribute-instance” of class higgins:StringAttribute
(a kind of higgins:Attribute) and (ii) by an RDF property “eyeColor”.
Taken together we express that [the Digital Subject] mary has attribute of type
eyeColor with the triple: (mary, eyeColor, attribute-instance).
If her eyeColor was green, then we express that with the triple: (attribute-instance, higgins:string, “green”). And now to add metadata… We express that “the
source of this attribute/value is the RMV” with the triple: (attribute-instance, hasSource, “RMV”). -Paul From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim It looks like now
that people are implementing and using IdAS, they dislike an aspect of the
model we defined at the 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? Jim |