RE: Sample schema extension models

I'll grant you that there is complexity, but I feel it is a valid model.
The need for Situations is that they represent the resting state of a
portion of the model (the existential facet) /between/ events.  Events
and Actions represent the kinetic portion of the model, and Situations
represent the static.  Although the proposed model (Event->Event->Event)
does model a chain of events, it does not indicate the time between the
events.  Is this a big deal?  Perhaps not.  However, the ABC model does
maintain the difference between the change and the result of the change,
which makes sense to me.

Now that everyone has digested the examples, I'd like to put a stake in
the ground regarding the current effort.  I'd like to propose that we
use the existing Harmony ABC properties -- hasPatient, creates, and
destroys -- for the current work.  These properties successfully model
the gamut of events that are presently captured in the History System.
Refinements will need to be defined by end users (or experts deploying
systems for them).  I would also propose that, since these properties
successfully capture the full semantics required for the current History
System, that we abandon sub-classing altogether for this revision.  The
most useful type information appears to be the type of object being
manipulated, and (at least in the present model) not the type of
manipulation.  This technique does /not/ preclude anyone from extending
the model (we are already requiring inferencing) and should not break
any clients that rely solely on ABC (as can be shown by running the same
RDQL query across all three models successfully).

-Jason

-----Original Message-----
From: www-rdf-dspace-request@w3.org
[mailto:www-rdf-dspace-request@w3.org] On Behalf Of Butler, Mark
Sent: Thursday, June 05, 2003 12:52 PM
To: 'Jason Kinner'; www-rdf-dspace@w3.org
Subject: RE: Sample schema extension models


Hi team, 

I've been puzzling over the graphs of these three examples all day. I'm
not
clear why we need this level of complexity, or what it buys us, apart
from
compatibility with Harmony. I don't like inheriting complexity, I think
we
should try to avoid it. One of the key ideas of extreme programming is
keep
out complexity until you are sure you need it, because it is always
easier
to refactor something that is simple than it is to refactor something
that
is complex. 

One of the problems is analysing the graphs in itself is quite hard,
because
as programmers we are not used to dealing with graphs that much. I
prefer to
think of things as tuples in database tables or as data objects. For
example
consider if we convert the first graph to data objects (apologies for
making
up a new notation here) we get 7 data objects:

urn1
 type: Created
 precedes: urn3
 hasAction: urn2
 hasPatient: hdl:1234/123

urn2
 type: Create
 creates: hdl:1234/123

urn3 
 type: Situation

urn4
 type: Modified
 hasPatient: hdl:1234/123
 preceds: urn5

urn5
 type: Situation

hdl:1234/123;1
 type: Item
 phaseOf: hdl:1234/123
 title: MyExample

hdl:1234/123;2
 type: Item
 phaseOf: hdl:1234/123
 title: Our Example

So we have this strange distinction between Events, Actions and
Situations,
but its not clear to me how this helps. For example I think we can
easily
use just 4 data objects to do the same thing e.g.

event1
 type: Creation
 precedes: event2
 hasResult: hdl:1234/123;1

event2 
 type: Modification
 follows: event1
 hasPatient: hdl:1234/123;1
 hasResult: hdl:1234/123;2

hdl:1234/123;1
 type: Item
 identity: hdl:1234/123
 version: 1
 title: MyExample

hdl:1234/123;2
 type: Item
 identity: hdl:1234/123
 version: 2
 title: Our Example

where

Modification ISAsubClass Event
Creation ISAsubClass Event

So can anyone explain why we need the additional complexity?

best regards,

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Thursday, 5 June 2003 15:50:14 UTC