Re: GUIDE: draft format how-to-do-it examples

Are we agreed that we will be using this format?
I have no objection (although make an augmentation suggestion below) but I am
about to write up a simple closed world notion using cardinality
and wanted to use the accepted format.

I had previously started to collect "tricks of the trade" how to do it cases
and had posted
http://www.ksl.stanford.edu/people/dlm/daml/modelingIssues.html
which contained a short writeup for capturing a notion of same-as.
That was last updated nov 2001 and had the format
task
observation (optional)
abstracted solution
daml+oil solution
references
acknowledgements

my task is guus's modeling problem,
my abstracted solution is basically a typical solution
daml+oil code (or owl code now) could be in an appendix but it will probably be
heavily used for cutting and pasting so i suggest that we add this to guus'
template.

are there other refinements/suggestions people have?
it will be easier for us if we get these out now before too many submissions are
made.

thanks,
deborah

Guus Schreiber wrote:

> FORMAT FOR OWL HOW-TO-DO-IT GUIDELINES
> First draft, July 21
>
> TITLE
> MODELLING PROBLEM
> - should include domain-specific example
> - should explain why modelling of this feature is not straightforward in OWL
> - include criteria required for this pattern to apply
> TYPICAL SOLUTION
> - modelling approach for the example
> - pattern: how to do this in general
> HINTS & TIPS
> - hints about typical modelling decisions
> - links to other patterns
> KNOWN USES & REFERENCES
> - links to applications that use this
> - links to relevant literature
>
> TITLE  Bi-directionality of relations between classes
>
> MODELLIN PROBLEM
>
> OWL properties differ from, for example, UML associations in the sense
> that OWL
> properties are directional (from subject to object) and thus models an
> association "from one side".
>
> Take for example the following UML association.
>
> [@@ Include fig with association "enrolment" between a student and a
> course.]
>
> In OWL, we would need to decide on the direction of the association,
> e.g. that the property goes from student to course. Also, adding
> cardinality (= multiplicity) constraints can only be done in OWL for
> one side of the association:. If the property is defined as student =>
> course, you can say how many courses a student may be enrolled in, but
> you cannot say how many students may be enrolled in a course.
>
> TYPICAL SOLUTION
>
> If you really need the "bi-directional" view on the association,
> you could define two properties, where one is the inverse of the
> other:
>
> [@@ include owl language fragments for the example]
>
> So in general, if you have a UML relation which is navigable from both
> sides, consider modelling it the following way in OWL:
> - Define two properties and define one of them as the "owl:inverseOf"
> the other property.
> - Choose directional names for the properties, similar to role names
> in a UML association
> - Attach range and cardinality constraints to the respective
> properties.
>
> HINTS & TIPS
>
> - Define the least frequently-used direction as the "inverseOf"
>    property.
> - @@
>
> KNOWN USES & REFERENCES
>
> @@.
>
> --
> A. Th. Schreiber, SWI, University of Amsterdam,
> Home page: http://www.swi.psy.uva.nl/usr/Schreiber/home.html

--
 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm/index.html
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705
0941

Received on Thursday, 15 August 2002 16:50:42 UTC