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

Sample schema extension models

From: Jason Kinner <jason_kinner@dynamicdigitalmedia.com>
Date: Wed, 4 Jun 2003 22:22:37 -0400
To: <www-rdf-dspace@w3.org>
Message-ID: <007801c32b09$58659c20$0400a8c0@STARGATE>
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?".
Received on Wednesday, 4 June 2003 22:22:49 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:35:24 EDT