RE: Re[4]: [higgins-dev] IdAS: One attribute per type per DS

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

I'm in agreement with this general approach.

> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Valery Kokhan
> Sent: Monday, April 30, 2007 11:57 AM
> To: 'Higgins (Trust Framework) Project developer discussions'
> Subject: Re[4]: [higgins-dev] IdAS: One attribute per type per DS
> 
> I've been thinking on how to adjust HOWL to allow metadata on both but
> still do not see any way to do this but if to think about the case
> where we need metadata on attribute level I think we can solve this if
> we allow our attributes to contains another attributes.
> 
> My proposal is to define our complex attribute as it can contains
> another attributes along with generic properties.
> 
> I'm hearing objections against like if we allow hierarchical structure
> of attributes we may run into infinite recursion if someone... But
> does this really a problem? A lot of application uses such kind of
> data structures and happy with that. If we restrict ourself to have
> only plain set of attributes the people may chose not to use higgins
> just because of this.
> 
> Valery
> 
> 
> Saturday, April 28, 2007, 8:17:39 PM, you wrote:
> 
> >
> >
> > Can the HOWL be adjusted such that we can have metadata on both?
> > Paul indicates that it can be done.  I haven't taken the time to
> > deep-dive into the HOWL on this issue yet myself.
> >
> >
> >
> > Jim
> 
> >>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/28/07 11:04 AM >>>
> > 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.
> 
> > 2) If we allow metadata on value level then we'll have to mutually
> > disjoin IAttribute and IProperty to make sure that they are operating
> > with different interpretation of values. Why? Because from OWL POV we
> > can put metadata on owl:ObjectProperty but it is impossible for
> > owl:DatatypeProperty. 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).
> 
> > 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