| Re: Re[2]: [higgins-dev] IdAS: One attribute per type per DS |
|
On #4, you realize you're introducing the very problem you want solved at the value level. That is: even if multiple same-typed attributes were allowed, in most instances there will only be a single attribute of that type. Forcing users to iterate over a set of one will seem burdensome, so someone will suggest either adding a getAttribute(URI) or introducing some kind of ISingleInstanceAttribute interface.
On #3, we've talked about use cases for having metadata at the value level, so I think we shouldn't discount allowing that. How it's done may not be by putting IHasMetadata on ISimpleValue. I think IHasMetadata would be either on IPropertyValue, or (if that's disallowed) we create an IAttributeValue which implements IPropertyValue and IHasMetadata -- this puts metadata at the value level, but not at sub-elements of complex values (which I think I just read was a concern).
On #2, I agree, it looks like we'd need a way to add metadata to an attribute's value assertion. Either that or proclaim that data as unsearchable (I prefer the former)
The initial assertion is somewhat different from what we have today. Today's model as described by IdAS allows multiple same-typed attributes, where each may have multiple values. Your proposal is different -- it seems like a pretty classic grouping decision as you present it. If we were to do this, the usual issues would need to be addressed -- like: When I call getAttributes(), can I rely on the Iterator to return same-types attributes contiguously, or must I wade through the entire list of attributes before knowing I've read all of the current type? No big deal, we just have to answer questions like that. I'm not sure if it changes search filter semantics or not -- I'd have to think about it.
Where it becomes an issue is that it removes the ability to put metadata at the attribute level. I can no longer place a "creationTime" or "modificationTime", or a "timeToLive" on the list of values as a whole -- I now have to copy it to all values. Copying data like this may or may not be bad -- depends on the use cases. One use case where it's worse than simple data proliferation is where I might want metadata which applies to all values of an attribute, and when that same metadata appears on a value, the value's metadata overrides that of the group. It might get sticky trying to track that kind of thing if we only have value-level metadata.
Jim
>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 4/28/07 12:47 PM >>> Paul, To have a single Attribute with multiple values is the same as to have a list of attibutes with single value. However I prefer to have a list of Attributes with single value by the following reasons: 1. We will need to make MUCH LESS changes to exist CP implementations (at least for Jena CP). 2. We will not need to change IFilter interfaces (it is already implemented for Jena CP). 3. I think it is not a good idea to move IHasMetadata from IAttribute to ISimpleValue. IHasMetadata depends on used schema, and I think it is not useful for BasicSimpleValues to implement this interface. 4. The problem of multiple Attributes is the same as the problem of multiple values and will be resolved in the same way ( perhaps we need to replace getAttribute(URI type) with getAttributes(URI type) for IDigitalSubject). Thanks, Sergey Lyakhov ----- Original Message ----- From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> To: "'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx> Sent: Saturday, April 28, 2007 8:55 PM Subject: RE: Re[2]: [higgins-dev] IdAS: One attribute per type per DS Valery wrote: > > 1) From HOWL POV I do not see a way to allow metadata on both > attribute and value level - we can have them at either attribute or > value but not on both. 1/2 of the problem is IS solved: We know how to have arbitrary metadata on a higgins:Attribute (soon to be renamed higgins:ValueWithMetadata (note the singular use of Value)), and, if we use N higgins:attribute predicates to point to N higgins:ValueWithMetadata instances we have the underlying representation, that, when surfaced at the IdAS API is presented as "one attribute per type with N values each of which N values can have arbitrary metadata". 1/2 of the problem that is not solved: With the above approach Valery is correct that we don't yet have a design for associating metadata with the entire SET of the N values mentioned above. We need to work on this. <snip> >In case of our favourite person-with-address.owl > example we can't put metadata on sub-values (pwa:state, pwa:country, > etc) of complex value (pwa:postalAddress). This is true. But I think we can live with this. Certainly for the immediate present. If one needs to associate metadata at a more granular level, one needs to not use Complex value types, but instead compose them from more atomic objects using some (as yet undefined) collection classes. This also needs design work. > > Valery > > > > So, my understanding is that there are these remaining issue: > > > > > > > > 1) Making sure we agree on how the Jean CP maps from the IdAS APIs to > the HOWL. > > > > 2) agreeing to allow/disallow metadata at the value level in the IdAS > APIs. > > > > > > > > On #2, I don't remember anyone saying disallow. > > > > > > > > I propose the following: > > > > > > > > a) Continue to allow metadata on IAttribute (this allows for the > > point below that Paul says IS important) > > > > b) Re-adjust the APIs to reflect the notion of one attribute per type > > > > b.1) This consists of removing the metadata arg from > > IHasAttributes.getAttribute(URI attrID, Iterator metadata) > > > > c) Make IPropertyValue extend IHasMetadata > > > > > > > > Jim > > > > >>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 4/27/07 10:05 AM >>> > > Jim wrote: > >> > >> >>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/27/07 9:22 AM >>> > >> >Jim, > >> > > >> >As I can remember our original assumption was that main difference > >> >between attributes and values is that attributes *can* hold metadatas > >> >while values *can not*. Regardless from the fact that I do not see any > >> >way to model metadata on values using .owl I believe that our original > >> >assumption was 100% correct and just leave it at this. > >> > > >> >Now about multiple attributes of the same type on any digital subject. > >> > > >> >Take into consideration above assumption I personally believe that on > >> >API level we should allow both approach: multiple attributes of the > >> >same type and multiple values in single attribute. > >> > >> So, historically at first the API allowed one attribute per type. Then > we > >> decided we needed to allow metadata to differ on same-typed attributes, > >> and thus introduced the ability to have multiple attributes per type. > >> This led to much confusion and rendered the > IDigitalSubject.getAttribute > >> method fairly useless. Why? Because now we have to indicate the > >> attribute's type along with all it's metadata to distinguish it from > other > >> attributes of the same type. Otherwise, which occurrence of that > attribute > >> should the CP return? > >> > >> So, a couple of phone calls ago, we agreed to revert back to allowing > only > >> one attribute per type, and at that time I believe we decided to allow > >> metadata to be placed on values. > > > Which aligns perfectly with higgins.owl. [As I mentioned I propose we > rename > > higgins:Attribute to higgins:ValueWithMetadata.] > > > What Jim is proposing is allowing only one attribute per type. Which > could > > be fine and convenient from the IdAS POV. It is handled (as always) from > the > > HOWL POV using multiple higgins:attributes each with ONE value and each > > value with some optional metadata. > > >> > >> >As a use case for multiple attributes of the same type I'd consider > >> >attribute like "relationship" where we need to keep track of when or > >> >by whom each particular relationship was created or modified. > >> > >> In this case, we could put the metadata on the values. > > > Correct. And in HOWL each SubjectRelationship instance (the "value") has > its > > its own metadata. We're aligned. > > >> > >> >As a use case for multiple values in single attribute I see attribute > >> >like "favoriteDrinks" where we don't care of when each particular > >> >value was modified by still want to know when entire list was changed. > >> <snip> > > > Jim, this/Valery's use case IS important. We need the ability to put > > metadata (e.g. timestamp of when the list was changed) on the entire > list of > > values. > > > I'll leave it to you to consider the IdAS API POV. > > > But from the HOWL POV perhaps we could introduce Lists as first class > > objects and solve the problem that way? We'd still have one attribute > per > > type, but the value might be a List (List of values). This List could > itself > > have metadata on it. > > > This would involve changing the HOWL to introduce a few new collection > > classes, like say, higgins:List, higgins:Set, etc. A List, for example, > > would be a kind of higgins:Attribute [what I'd prefer to call > > higgins:ValueWithMetadata]). I have to think about it some more, but it > > might be workable. > > > > > _______________________________________________ > > 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 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |