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

[Roger L. Costello]

> 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?
>

Yes, I meant to say -

M10a-Rev-1) The type of the value of a measurement property of a
LinearPhysicalQuantity is a LinearMeasurement.

> -----------------------------------------------------------------
> > M1) A TangibleObject may have zero or more PhysicalProperties.
>
> Don't you mean "... zero or more physicalProperties"?
>

Yes, just so.

> -----------------------------------------------------------------
> > M12) A (numerical value, units specification) pair is a kind of
> > MeasurementValue.
>
> Don't you mean "... is a kind of Measurement"?
>

No, I meant it as written, but this part is a little weak because I did not
yet come up with terminology and a new type of thing.  Here's the idea -

from M11 - A LinearMeasurement is characterized by one or more equivalent
(numerical value, units specification) pairs.

This pair is supposed to be the "value" of the measurement, but not the
measurement itself, which can have many other attributes (see M13).  Now,
how can we have this pair be talked about together as a unit?  There has to
be a thing for the pair.  Otherwise, we would not be able to comply with
M14 -

M14 ) There is at least one method for establishing the equivalence between
each (numerical value, unit specification) pair of interest.

You do not want to establish an equivalence between all the meta data about
a measurement, just the (value,units) pair (eg., 1 inch is "equivalent" to
2.54 cm)

Let us temporarily call the pair "LinearValuePair".  Then (I hope) what I
wrote amounts to this -

M12-rev-1) A LinearValuePair is a kind of MeasurementValue.
M12-a-rev-1) The type of the value of the characteristic property of a
LinearMeasurement is a LinearValuePair.

Is this clear enough?

> -----------------------------------------------------------------
> >     T-M1-3.  The domain of PhysicalProperty is TangibleObject.
>
> Don't you mean "The domain of physicalProperty is ..."?
>

Right.

> -----------------------------------------------------------------
> > 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?
>

You don't think MITRE would let you put it in the DMZ?  I'm pretty sure I
could get one approved by INFOSEC at Mitretek.  MITRE must have dozens if
not hundreds of servers in the DMZ already.  Your ISP shouldn't care about
another server with a tiny bandwidth.  You already have a server that the
public can access, I know.  Isn't that in the MITRE DMZ?

>
> 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.
>

Well, I think a diagram would do wonders.  I just did not want to attach one
to a posting.  I think both are needed.  The diagram helps one (or at least
me!) to keep things straight, and the natural-language text makes helps to
make sure that you know how to translate the diagram.  I am also at the
limit of my ability to keep the model straight without a diagram or some
organization like you are doing below.

We absolutely should keep the conceptual model separate from RDF, and
especially from RDF/XML syntax.  What if the most natural model should be
un-doable in RDF?  It would be fine to come up with a workaround just for
RDF, but that should not change the model.  It would be like using a join
table in a relational database because you could not have a list-valued data
entry.  You have to do it but you do not change your conceptual model.
(Well,  of course the way you structure the model has _something_ to do with
the intended implementation, but I hope you get my point).

But much as I like XML, I wouldn't use it for delineating the design -
indentation by itself, absolutely yes.  That's good, at least until things
stop being a nice neat hierarchy.

The text statements are also very useful for devising the unit tests.

> -----------------------------------------------------------------
> Conceptual Model Framework
>
> <TangibleObject>
>    <physicalProperty>
>       <PhysicalQuantity>
>          <measurement>
>             <Measurement>
>                <numericalValue>
>                <unitSpecification>
>

Hmm, see below ...

> -----------------------------------------------------------------
> 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?
>

physicalProperty
   arealPhysicalProperty
      area

Hmm, need to think some more about whether there is any significant
difference between linearPhysicalProperty and length.  Maybe they are really
synonyms and we can cut out one level.  Any one else want to contribute
here?  My idea was that there are many kinds of linearPhysicalProperties,
and "length" is only one of them.  For example, there could be "width" as
well, and "height", and "thickness".  They are all linearPhysicalProperties,
that is why I had the third layer.  Much as I would like to cut out the
third level, I still think that it is correct modeling to keep it.

> -----------------------------------------------------------------
> Conceptual Model Class Hierarchies:
>
>     PhysicalQuantity
>          |
>          |
>   LinearPhysicalQuantity
>

PhysicalQuantity
    ArealPhysicalQuantity

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

I am not sure that you need a separate "Length" type.  The role of the
LinearPhysicalQuantity is established by the predicate's type (e.g.,
"length" or "thickness"), and the structure of the object - the
LinearPhysicalQuantity - in all cases would be the same.  So where would the
advantage be in having a Length, a Width, and a Thickness?  I do not see a
benefit.  So in the interest of "As Simple As Possible", I do not think they
are needed.
>
> -----------------------------------------------------------------
> 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?
>

Not quite.  With the additions (i.e., M12-Rev-1) I made above, I think it is

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

I would like to see the RDF fragment run through an RDF processor that
output triples in a very readable syntax (N3?), and then compare the triples
against the triples derived from the model.  This would decouple the triples
part, which is the real heart of the thing, from the vagaries of RDF/XML
syntax.

We - or really __you__ :-) need to pull together the collection of candidate
tests at this point.  They should be cast into clear, simple language so far
as possible (like my examples, I hope!).

> Again, great stuff Tom!  /Roger

:-)

Cheers,

Tom P

Received on Saturday, 5 July 2003 15:31:36 UTC