W3C home > Mailing lists > Public > www-rdf-dspace@w3.org > June 2003

RE: Sample schema extension models

From: Jason Kinner <jason_kinner@dynamicdigitalmedia.com>
Date: Thu, 5 Jun 2003 15:49:59 -0400
To: "'Butler, Mark'" <Mark_Butler@hplb.hpl.hp.com>, <www-rdf-dspace@w3.org>
Message-ID: <00a901c32b9b$aa75fbd0$0400a8c0@STARGATE>

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


-----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
clear why we need this level of complexity, or what it buys us, apart
compatibility with Harmony. I don't like inheriting complexity, I think
should try to avoid it. One of the key ideas of extreme programming is
out complexity until you are sure you need it, because it is always
to refactor something that is simple than it is to refactor something
is complex. 

One of the problems is analysing the graphs in itself is quite hard,
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
consider if we convert the first graph to data objects (apologies for
up a new notation here) we get 7 data objects:

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

 type: Create
 creates: hdl:1234/123

 type: Situation

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

 type: Situation

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

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

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

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

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

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

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


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
Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Thursday, 5 June 2003 15:50:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:13:06 UTC