[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[6]: [higgins-dev] IdAS: One attribute per type per DS
|
It appears to me that this question was one of the reasons why I
proposed to allow hierarchical structure of attributes.
Valery
Tuesday, May 1, 2007, 3:36:20 PM, you wrote:
>
>
> Will there be an alternative way to get attribute level metadata?
> In the case of creating an attribute, an application may need to
> know certain metadata that applies to all values. For example, Input
> charatceristics: text box, 40 characters long, default values; and
> validation rules: all lower case, no special characters.
>
> David
>
> David Kuehr-McLaren
> Tivoli Security
> 919.224.1960
>
>
>
> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> Sent by: higgins-dev-bounces@xxxxxxxxxxx
> 05/01/2007 08:21 AM
>
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
>
>
> To
> "'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
> cc
>
> Subject
> RE: Re[4]: [higgins-dev] IdAS: One attribute per type per DS
>
>
>
>
> We changed our opinion on this one. Last week I echoed Valery that
> it was a valid requirement, but I said no on #1 here because as we
> have looked the difficulty of expressing it in HOWL, and the
> complexity/confusion it introduces, were now thinking that well try to live without it.
>
>
>
> From: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> Sent: Tuesday, May 01, 2007 12:21 AM
> To: 'Higgins (Trust Framework) Project developer discussions'
> Subject: RE: Re[4]: [higgins-dev] IdAS: One attribute per type per DS
> Oh, I thought it was you that was asking for metadata to be
> associated at the attribute level (such that some metadata could be
> associated with its set of values)
>
>>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 4/30/07 11:01 PM >>>
> 1. no
> 2. yes
> 3. yes
> 4. yes
>
>
>
> From: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> Sent: Monday, April 30, 2007 11:55 PM
> To: 'Higgins (Trust Framework) Project developer discussions'
> Subject: RE: Re[4]: [higgins-dev] IdAS: One attribute per type per DS
> Are we saying all of these, or a subset?:
> 1) an attribute may have metadata
> 2) an attribute's simple value may have metadata
> 3) a attribute's complex value may have metadata
> 4) elements (and sub-elements) of an attribute's complex value may have metadata
> If it means all of these, one would be tempted to represent this is
> IdAS by putting moving IHasMetadata to IProperty and IPropertyValue.
> Looks good at first until you see that currently IMetadata extends
> IProperty (meaning IdAS would present a model where even metadata could have metadata).
>
> Anyway, let's decide what it means for sure, then we can make IdAS behave properly.
>
>>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 4/30/07 10:06 PM >>>
> 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
>
> _______________________________________________
> 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
>
>
