Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Two bug fixes toHOWL(higgins.owl)[nonbreakingchange]

SergeyL wrote:
> 
> Paul,
> 
> 1. Of course, there is a posibility on HOWL level for SimpleValue to have
> Attributes. But I and Valery assume that simple value shlould not have
> Attributes (and I suppose Jim thinks so, because now ISimpleValue
> interface
> doesn't extend IHasAttributes). Simple value should be really simple.
> Otherwise, ISimpleValue interface should extend IHasAttributes interface.

Agreed. 

But you and I are specifically discussing the range of the higgins:attribute
ObjectProperty. And I maintain that a higgins:attribute have a range that is
either a SimpleValue or a ComplexValue. One way to capture this semantic is
to say that the range of a higgins:attribute is Value. And that's they way
it is in HOWL.

> 
> 2.
> 
> > > The higgins:Attribute is a holder of metadata for a set of
> > higgins:Values.
> 
> There is one problem related to metadata of attribute. We need to describe
> which kinds of metadata can attibute have. We do it setting appropriate
> class - holder of metadata as domain of appropriate metadata property. If
> we
> assume that each attribute should have some default metadata set
> (higgins:validFrom, higgins:lastModified etc.), these metadata properties
> should have hggins:Attribute class as domain.

True. I have not done this yet. 

> Then, suppose, we create simple attribute with type higgins:name
> (higgins:name is subproperty of higgins:attribute). There is two possible
> cases:
> 
> a) we do not need any additional type of metadata for this new attribute.
> As
> a result we can use higgins:Attribute to hold metatada of this attribute.
> 
> b) we need to define additional metadata for this attribute. As result we
> should create new class - holder of metadata for this attribute (suppose
> higgins:NameAttribute, that is subclass of higgins:Attribute).

True. 

> 
> The question is - should we always create new subclass of
> higgins:Attribute
> for each new subproperty of higgins:attribute (even if this attribute does
> not require new metadata types)? I prefer to always create new subclass of
> higgins:Attribute.

Interesting. We will know better when we have more experience with use cases
whether or not the most common case is your (a) or (b) above. Is it because
you think (b) will be the most common that you prefer to mandate that a new
higgins:Attribute be defined? Or is there some other reason? 

> 
> Thanks,
> Sergey Lyakhov
> 
> ----- Original Message -----
> From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> To: "'Higgins (Trust Framework) Project developer discussions'"
> <higgins-dev@xxxxxxxxxxx>
> Sent: Saturday, May 26, 2007 1:07 AM
> Subject: RE: [higgins-dev] Two bug fixes
> toHOWL(higgins.owl)[nonbreakingchange]
> 
> 
> >
> >
> > Sergei wrote:
> >>
> >> > Both ComplexValue and SimpleValue are sub-classes of Value. By
> stating
> >> the
> >> > range as Value we allow both possibilities.
> >>
> >> Of course, they both are sub-classes of Value. But SimpleValue can not
> >> have
> >> attributes (at least ISimpleValue interface doesn't extend
> >> IHasAttributes,
> >> because there is no any sence for SimpleValue to have attributes).
> >
> > Let's start over here. You originally wrote:
> >   1. SimpleValue can not contain attributes (only ComplexValue can), so
> >   it will be more correct to allow the range of higgins:attribute to be
> >   ComplexValue, not Value.
> >
> > In addition to cases where the range might be a ComplexValue, I can
> > imagine
> > a higgins:attribute sub-property that has a range of SimpleValue. Here's
> > one: eyeColor. An instance of eyeColor would have a domain of <some DS>
> > and
> > a range of higgins:String. (A higgins:String is a subclass of
> > higgins:SimpleValue). Thus I maintain that since a higgins:attribute's
> > range
> > might be a ComplexValue and it might be a SimpleValue, then to allow
> > either
> > one, it should be specified as Value, the superclass of both.
> >
> >>
> >> Also I have one question about metadata: let's suppose that we have
> >> attribute with 2 values and one metadata container (higgins:Attribute)
> as
> >> it
> >> was in your example. The question is - what should we do with metadata
> >> when
> >> both values were removed from attribute? Should we delete metadata when
> >> we
> >> remove last value of attribute?
> >
> > Yes, I think what you propose is the correct convention.
> >
> >>
> >> Thanks,
> >> Sergey Lyakhov
> >>
> >> ----- Original Message -----
> >> From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> >> To: "'Higgins (Trust Framework) Project developer discussions'"
> >> <higgins-dev@xxxxxxxxxxx>
> >> Sent: Friday, May 25, 2007 8:08 PM
> >> Subject: RE: [higgins-dev] Two bug fixes to HOWL
> >> (higgins.owl)[nonbreakingchange]
> >>
> >>
> >> >
> >> > SergeyL wrote:
> >> >>
> >> >> Paul,
> >> >>
> >> >> > 2) bug fix: allowed the range of higgins:attribute to be either
> >> >> > higgins:Value (as it was) or higgins:Attribute (new--this object
> is
> >> the
> >> >> > holder of metadata about the entire set of values (i.e. "ranges")
> of
> >> a
> >> >> set
> >> >> > of higgins:attributes
> >> >>
> >> >> 1. SimpleValue can not contain attributes (only ComplexValue can),
> so
> >> it
> >> >> will be more correct to allow the range of higgins:attribute to be
> >> >> ComplexValue, not Value.
> >> >
> >> > Both ComplexValue and SimpleValue are sub-classes of Value. By
> stating
> >> the
> >> > range as Value we allow both possibilities.
> >> >
> >> >>
> >> >> 2. Really higgins:attribute is a property of DS (or complex value)
> >> >> that
> >> >> contains higgins:Value (simple or complex). What sence is there for
> >> >> higgins:Attribute class to be the range of  higgins:attribute? Do
> you
> >> >> mean
> >> >> that we should use the same property to store as values of attribute
> >> >> as
> >> >> metadata of this attribute?
> >> >
> >> > All will become more clear as I work on some examples. But here is
> >> > where
> >> > I'm
> >> > headed...
> >> >
> >> > The higgins:Attribute is a holder of metadata for a set of
> >> higgins:Values.
> >> >
> >> > Here is an example of its use: Consider foo:eyeColor to be a property
> >> > of
> >> a
> >> > DS (a sub-property of higgins:attribute property). Imagine three
> >> instances
> >> > of this eyeColor property: two of them point to higgins:Values (e.g.
> >> > two
> >> > higgins:Strings having associated literal values of "blue" and
> "green"
> >> > respectively), and the third points to a higgins:Attribute that holds
> >> > metadata about the set of Values. As a trivial example, this
> >> > higgins:Attribute could hold the metadata property "numberOfValues"
> and
> >> > have
> >> > a range/value of "2".
> >> >
> >> > Thus the metadata (numberOfValues = 2) is bound to the values
> >> > ("blue","green") as follows:
> >> >  * the relevant ObjectProperty instances (all three of them) have the
> >> same
> >> > URI (in our example, "foo:eyeColor)
> >> >  * we follow a convention that there is at most one higgins:Attribute
> >> > instance for a given higgins:attribute sub-property
> >> >
> >> > -Paul
> >> >
> >> >>
> >> >> Thanks,
> >> >> Sergey Lyakhov
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> >> >> To: "'Higgins (Trust Framework) Project developer discussions'"
> >> >> <higgins-dev@xxxxxxxxxxx>
> >> >> Sent: Friday, May 25, 2007 6:01 PM
> >> >> Subject: [higgins-dev] Two bug fixes to HOWL (higgins.owl) [non
> >> >> breakingchange]
> >> >>
> >> >>
> >> >> > 1) bug fix: allowed the domain of higgins:attribute to be either
> >> >> > DigitalSubject (as it was) or ContextObject (new)
> >> >> >
> >> >> > 2) bug fix: allowed the range of higgins:attribute to be either
> >> >> > higgins:Value (as it was) or higgins:Attribute (new--this object
> is
> >> the
> >> >> > holder of metadata about the entire set of values (i.e. "ranges")
> of
> >> a
> >> >> set
> >> >> > of higgins:attributes
> >> >> >
> >> >> > Changes have been published here [1]
> >> >> >
> >> >> > [1] http://www.eclipse.org/higgins/ontologies/2006/higgins.owl
> >> >> >
> >> >> > -Paul
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top