Re: FW: Re: (Round 2) Proposed Extensions to OWL

Excellent Tom!  This provides much needed structure to
what we have been doing.  

I have several comments:

-----------------------------------------------------------------
> M8) The type of the value of a length is a LinearPhysicalQuantity

> M10a) The type of the value of a length property is a LinearMeasurement.

Don't these contradict each other?

-----------------------------------------------------------------
> M1) A TangibleObject may have zero or more PhysicalProperties.

Don't you mean "... zero or more physicalProperties"?

-----------------------------------------------------------------
> M12) A (numerical value, units specification) pair is a kind of
> MeasurementValue.

Don't you mean "... is a kind of Measurement"?

-----------------------------------------------------------------
>     T-M1-3.  The domain of PhysicalProperty is TangibleObject.

Don't you mean "The domain of physicalProperty is ..."?

-----------------------------------------------------------------
> Roger, are you going to start up a Wiki for this?

I have never set one up.  I know my company wouldn't allow it for
security reasons.  I am not sure that my ISP allows it.  Anyone know if
ISP's generally allow such things?

-----------------------------------------------------------------

I suspect that your idea of keeping the conceptual model independent of
RDF is a good one.  However, I soon got lost when reading all the
conceptual model statements, and found myself jotting them down in
XML-type notation.  Below are my scribbles (along with several
questions).  Perhaps others with find them of benefit.

-----------------------------------------------------------------
Conceptual Model Framework

<TangibleObject>
   <physicalProperty>
      <PhysicalQuantity>
         <measurement>
            <Measurement>
               <numericalValue>
               <unitSpecification>

-----------------------------------------------------------------
Conceptual Model Applied to a TangibleObject which has a length:

<TangibleObject>
   <length>
      <LinearPhysicalQuantity>
         <measurement>
            <Measurement>
               <numericalValue>
               <unitSpecification>

-----------------------------------------------------------------
Conceptual Model Property Hierarchies:

    physicalProperty
          |
          |
  linearPhysicalProperty
          |
          |
        length

Question: How would "area" fit into this property hierarchy?

-----------------------------------------------------------------
Conceptual Model Class Hierarchies:

    PhysicalQuantity
         |
         |
  LinearPhysicalQuantity

Question: Would it be useful to say that Length is a type of
LinearPhysicalQuantity?

    Measurement
         |
         |
  LinearMeasurement

-----------------------------------------------------------------
Concrete Example that Conforms to the Conceptual Model:

<River rdf:ID="Yangtze">
   <length>
      <LinearPhysicalQuantity>
         <measurement>
            <Measurement>
               <numericalValue>6300</numericalValue>
               <unitSpecification rdf:resource="#LengthInKilometers"/>
            </Measurement>
         </measurement>
      </LinearPhysicalQuantity>
   </length>
</River>

Question: do you agree that this example faithfully conforms to the
conceptual model?  

Again, great stuff Tom!  /Roger

"Thomas B. Passin" wrote:
> 
> [Roger L. Costello]
> >
> > The discussions have been excellent.  I believe that we are making good
> > progress.
> >
> 
> We are, but I think it is time for a change in how to proceed - I have
> several suggestions.
> 
> It struck me this morning that this process is very much like the Pair
> Programming of Extreme Programming.  One person writes code (==>RDF) and the
> others look on, making suggestions and pointing out errors.  Then another
> person takes up the code-writing role.
> 
> But some of the other key practices from Extreme Programming are missing.  I
> think that they should be in play here.
> 
> 1) Write unit tests before writing code.
> 2) Test constantly by applying the unit tests.
> 3) Refactor diligently.
> 4) Be as simple as possible.
> 
> The unit tests are based on the known requirements for a module plus what is
> learned during development.  Tests are added but not normally retired.
> 
> When all unit tests pass and no one can think of any other applicable tests,
> you are done (until I & T, etc, which I take it we are not tackling here).
> 
> The input requirements in this case would be based on a conceptual model of
> some kind, together with the kind of statements we think we will want to
> make.  As for the tests, we know that we want to be able to make statements
> and draw inferences.  So the tests must be in the form of statements.  They
> cannot be in RDF because we do not yet know what the RDF will be.  Therefore
> they need to be in some other language.  In practice, I am sure we want to
> use natural language.
> 
> We already know that we are talking about _kinds_ of statements,  but we
> will have to test them with specific instance statements.  We also know that
> there are a potentially infinite number of statements we would eventually
> like to be able to make.  We cannot test them all, so we will have to be
> smart about crafting our tests.  Of course we will learn and add tests as we
> go.
> 
> Below I take first cut at this plan.  But before that, here comes my other
> suggestion.  I think that this bit of development should get moved off the
> list to a (publicly accessible) Wiki or Blog site.  If a blog, it should
> accept comments to each story, and display them in line.  As an Wiki
> example, you could look at Sam Ruby's Wiki for the Echo project.  It looks
> like it uses the Moin-Moin Wiki engine, which is in Python and is very easy
> to set up [ http://moin.sourceforge.net/ ].  There are many others.
> 
> Whether Wiki or blog, it would be useful to have an RSS feed for changes.
> 
> Now for the start of a conceptual model and a few unit tests.  I hope that
> the names I use are sufficiently clear, but if they are not, we need to
> improve them or to clarify their intent.  I begin property names with
> lowercase, object names with upper case, as Roger has been doing.
> 
> M1) A TangibleObject may have zero or more PhysicalProperties.
>     Note - Probably needs a different name for TangibleObject.
> 
> M2) A physicalProperty is a kind of Property.
> 
> M3) The type of the value of a physicalProperty is a PhysicalQuantity.
> 
> M4) A linearPhysicalProperty is a kind of physicalProperty.
> 
> M5) A length is a kind of linearPhysicalProperty.
> 
> M6) A PhysicalQuantity may be characterized by zero or more measurement
> properties.
> 
> M7) A LinearPhysicalQuantity is a kind of PhysicalQuantity.
> 
> M8) The type of the value of a length is a LinearPhysicalQuantity
> M8a).  A LinearPhysicalProperty may have one or more length properties.
> 
> M9) The type of the value of a measurement is a Measurement.
> 
> M10) A LinearMeasurement is a kind of Measurement.
> 
> M10a) The type of the value of a length property is a LinearMeasurement.
> 
> M11)  A LinearMeasurement is characterized by one or more equivalent
> (numerical value, units specification) pairs.
>     Note - This refers to the values in different units, not to the results
> of different measurements taken at different times or by different methods.
> 
> M12) A (numerical value, units specification) pair is a kind of
> MeasurementValue.
>     Note - I do not try to model a "units specification here".  That looks
> like a substantial     job in itself!
> 
> M13) A MeasurementValue may be associated with metadata that include -
>     a) Accuracy
>     b) Precision
>     c) Data set
>     d) Calculations
>     e) Algorithms used for the calculation.
>     f) Relevant publications
>     g) Source
>     h) Reported precision (i.e., number of decimal places in the stated
> value,
>         which may be different from the precision of the measurement)
> 
> M14) There is at least one method for establishing the equivalence between
> each (numerical value, unit specification) pair of interest.
> 
> I will stop here and give an example of a few unit tests for bits of this
> model.
> 
> - M1) A TangibleObject may have zero or more PhysicalProperties.
>     T-M1-1.  There is a type of Thing called TangibleObject.
>     T-M1-2.  There is a type of Property called Physical Property.
>     T-M1-3.  The domain of PhysicalProperty is TangibleObject.
>     T-M1-4.  A TangibleObject may have zero or more PhysicalProperties.
> 
> To perform these four unit tests, write an RDF or OWL statement for each of
> them.  This will be easy - so far so good.
> 
> M12) A (numerical value, units specification) pair is a kind of
> MeasurementValue.
>     - T-M12-1.  There is a kind of thing called MeasurementValue.
>     - T-M12-2.  A MeasurementValue must have exactly one numerical value.
>     - T-M12-3.  A Measurement Value must have exactly one units
> specification.
> Note - this is not quite right, because a general MeasurementValue could be
> more general than a simple (value, units) pair.  We need a name for the
> pair - then the test can be fixed.
> 
> We want other unit tests as well.  Each of Roger's challenges can be seen as
> a unit test.  We might even have a test that requires a specific inference
> to be found.
> 
> - T-Roger-1.  The Yangtze River has a length of 3609 miles.
> The unit test consists of
>     a) Translating the sentence into the language of the model.
>     b) Translating that into RDF/OWL statements.
> Probably, step (a) should really be included in the statement of the unit
> test, leaving only step b) to be actually tested.
> 
> - T-Roger-2.  The Yangtze River has a length of 6300 kilometers.
> - T-Roger-3.  The statements in T-Roger-1 and T-Roger-2 are equivalent.
>     -Note - This would seem to be impossible to pass  since we have not
> modeled what this kind of "equivalence" means as yet.  But maybe we can
> finesse it by using a symmetric "equivalentPhysicalValues" property, which
> we could define elsewhere.  The notion of "transformation" would get
> refactored into this new property.
> 
> If this seems like a good idea, we should add it to the conceptual model.
> 
> It looks to me like M14 and the units specification are the only tricky
> parts of this.
> 
> Guys, this has got to be a good approach, because my ideas changed,
> clarified, and improved as I wrote this post!
> 
> Just to sum up, I am suggesting this -
> 
>     Create a conceptual model and a set of typical
>     or edge case statements, then write unit tests for
>     each bit of the model and for each of the statements,
>     then try to write RDF/OWL for each test.
> 
> Roger, are you going to start up a Wiki for this?
> 
> Cheers,
> 
> Tom P

Received on Saturday, 5 July 2003 14:23:08 UTC