| RE: Re[4]: [higgins-dev] IdAS: One attribute per type per DS |
| "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 05/01/2007 08:21 AM
|
|
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
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