RE: Sample schema extension models

To check I understand what is going on, I produced the attached N3 files and
expliticly added subclass / subproperty rules.

Jason - did I get them right?

	Andy

-----Original Message-----
From: Jason Kinner [mailto:jason_kinner@dynamicdigitalmedia.com] 
Sent: 5 June 2003 03:23
To: www-rdf-dspace@w3.org
Subject: Sample schema extension models


All -

Below are three examples.  The scenario is quite simple: an Actuality is
created with a certain property value.  This property value is then changed.
The three different examples have very little that is different between
them, besides some additional productions produced by the inferencing
engine.  I have my own commentary inline.  Let's stick with this simple
example for now, and I will try to produce a more complex example involving
actual schema extension within the day.  One difficulty I had in analyzing
these models was that "creates" and "modifies" are effectively modeled using
the "creates" and "hasPatient" properties of Harmony ABC.

-Jason

PS - I leave it as an exercise for the reader to pump these XML
representations through the RDF Validator [1] to produce graphs and/or
tuples.

[1] http://www.w3.org/RDF/Validator/

Example 1:

Using only Harmony ABC properties with sub-classes for Action, Event, and
Actuality classes:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xml:base="http://dspace.org/history/1.0#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:abc="http://www.metadata.net/harmony#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dsh="http://dspace.org/history/1.0#"
>
  <dsh:Created rdf:about="urn:1">
    <abc:hasAction>
      <dsh:Create rdf:about="urn:2">
        <abc:creates rdf:resource="hdl:1234/123"/>
      </dsh:Create>
    </abc:hasAction>
    <abc:hasPatient rdf:resource="hdl:1234/123"/>
    <abc:precedes rdf:resource="urn:3"/>
  </dsh:Created>
  <abc:Situation rdf:about="urn:3">
  </abc:Situation>
  <dsh:Item rdf:about="hdl:1234/123;1">
    <dc:title>My Example</dc:title>
    <abc:inContext rdf:resource="urn:3"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </dsh:Item>
  <dsh:Modified rdf:about="urn:4">
    <abc:hasPatient rdf:resource="hdl:1234/123"/>
    <abc:follows rdf:resource="urn:3"/>
    <abc:precedes rdf:resource="urn:5"/>
  </dsh:Modified>
  <abc:Situation rdf:about="urn:5">
  </abc:Situation>
  <dsh:Item rdf:about="hdl:1234/123;2">
    <dc:title>Our Example</dc:title>
    <abc:inContext rdf:resource="urn:5"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </dsh:Item>
</rdf:RDF>

Notes: Seems useful.  Does not restrict existing (or, presumably, new)
properties, but does provide type information that can be used to restrict
result set on query (e.g. - What "Bitstreams" have changed?).  New
properties would provide a way to select for types of change (e.g. - What
"Bitstreams" have had their "format" changed?)

Example 2:

Using only derived properties and ABC classes:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xml:base="http://dspace.org/history/1.0#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:abc="http://www.metadata.net/harmony#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dsh="http://dspace.org/history/1.0#"
>
  <abc:Event rdf:about="urn:1">
    <abc:hasAction>
      <abc:Action rdf:about="urn:2">
        <dsh:createsItem rdf:resource="hdl:1234/123"/>
      </abc:Action>
    </abc:hasAction>
    <abc:hasPatient rdf:resource="hdl:1234/123"/>
    <abc:precedes rdf:resource="urn:3"/>
  </abc:Event>
  <abc:Situation rdf:about="urn:3">
  </abc:Situation>
  <abc:Actuality rdf:about="hdl:1234/123;1">
    <dc:title>My Example</dc:title>
    <abc:inContext rdf:resource="urn:3"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </abc:Actuality>
  <abc:Event rdf:about="urn:4">
    <dsh:modifies rdf:resource="hdl:1234/123"/>
    <abc:follows rdf:resource="urn:3"/>
    <abc:precedes rdf:resource="urn:5"/>
  </abc:Event>
  <abc:Situation rdf:about="urn:5">
  </abc:Situation>
  <abc:Actuality rdf:about="hdl:1234/123;2">
    <dc:title>Our Example</dc:title>
    <abc:inContext rdf:resource="urn:5"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </abc:Actuality>
</rdf:RDF>

Notes:
Loses validation of Actuality properties by removing type information; seems
to be a valuable place for validation.
Also, changes in type (which do occur after accession) cannot be managed
using this model.

Example 3:

Using sub-properties and sub-classes:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xml:base="http://dspace.org/history/1.0#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:abc="http://www.metadata.net/harmony#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dsh="http://dspace.org/history/1.0#"
>
  <dsh:Created rdf:about="urn:1">
    <abc:hasAction>
      <dsh:Create rdf:about="urn:2">
        <dsh:creates rdf:resource="hdl:1234/123"/>
      </dsh:Create>
    </abc:hasAction>
    <abc:hasPatient rdf:resource="hdl:1234/123"/>
    <abc:precedes rdf:resource="urn:3"/>
  </dsh:Created>
  <abc:Situation rdf:about="urn:3">
  </abc:Situation>
  <dsh:Item rdf:about="hdl:1234/123;1">
    <dc:title>My Example</dc:title>
    <abc:inContext rdf:resource="urn:3"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </dsh:Item>
  <dsh:Modified rdf:about="urn:4">
    <dsh:modifies rdf:resource="hdl:1234/123"/>
    <abc:follows rdf:resource="urn:3"/>
    <abc:precedes rdf:resource="urn:5"/>
  </dsh:Modified>
  <abc:Situation rdf:about="urn:5">
  </abc:Situation>
  <dsh:Item rdf:about="hdl:1234/123;2">
    <dc:title>Our Example</dc:title>
    <abc:inContext rdf:resource="urn:5"/>
    <abc:phaseOf rdf:resource="hdl:1234/123" />
  </dsh:Item>
</rdf:RDF>

Notes: Redefining ABC properties just to restrict scope doesn't seem to add
much value to queries.  It would seem redundant to produce a property called
"modifiesItem" just to restrict the range of the property (not that
redundancy is always a bad thing).  If I throw out query complexity, I would
rather allow the user to query for "What things were modified?" and require
a type qualifier for "What Items were modified?".