| Re: Re[2]: [higgins-dev] IdAS: One attribute per type per DS |
|
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 |