RE: Representing distinct item states

Hi Jason, team, 

(Also Dan Brickley - your comments may be useful here?)

> hdl:1271.1/5678 ----- harmony:hasRealization ----> hdl:1271.1/5678;1
>                 ----- harmony:hasRealization ----> hdl:1271.1/5678;2
> hdl:1271.1/5678;1 ----- dcq:isReplacedBy -----> hdl:1271.1/5678;2
> hdl:1271.1/5678;2 ----- dcq:replaces -----> hdl:1271.1/5678;1

Personally I would just do this:

dcq:isReplacedBy -- rdf:type --> owl:ObjectProperty
dcq:isReplaces -- rdf:type --> owl:ObjectProperty
dcq:isReplacedBy -- owl:inverseOf --> dcq:isReplaces

We don't have a body of theory that explains the "best" way to make semantic
web models, but we can look to relational database theory. This advocates
striving to minimize model complexity via normalization, so my preference
would be to adopt a similar approach. So rather than specifying both
relationships everywhere, it's better to state the relationship once and
infer. I guess others may not share this view: for example I note David
Karger has expressed a preference to add triples rather than rely on
inferencing so this is a moot point. 

> hdl:1271.1/5678 ----- owl:sameIndividualAs -----> 
> hdl:1271.1/5678;2 (the
> current revision)

I'm not sure about this. I interpret the formal semantics of
sameIndividualAs as meaning they are literally the same, so if you queried
what is dc:title of hdl:1271.1/5678 you'd now get "My Super Researck Paper"
and "My Super Research Paper". I don't think you want that - you want to
indicate they are related but separate. 

Having said that, I may be wrong because I re-read OWL documentation but it
didn't help:
http://www.w3.org/TR/2003/WD-owl-guide-20030210/#owl_sameIndividualAs
http://www.w3.org/TR/owl-semantics/syntax.html#owl_sameIndividualAs_syntax
http://www.w3.org/TR/owl-semantics/direct.html#owl_sameIndividualAs_semantic
s
http://www.w3.org/TR/owl-semantics/mapping.html#owl_sameIndividualAs_mapping
http://www.w3.org/TR/owl-semantics/rdfs.html#owl_sameIndividualAs_rdf
In theory the test suite should help here, but the test suite doesn't cover
sameIndividualAs although it does note this deficiency - see
http://www.w3.org/TR/owl-test/#editorialTestRelated
Also owl:sameIndividualAs comes from daml:sameIndividualAs and I've tried
searching for information on that to no avail. So before you use this, I'd
strongly recommend you at least query it with the people using OWL to check
your usage is correct. My guess is you need to do something like this
although again I think I'd query it with the OWL folks first:

dcq:modificationOf -- rdf:type --> owl:ObjectProperty
dcq:modificationOf --> rdfs:range --> owl:Thing
dcq:modificationOf --> rdfs:domain --> owl:Thing
dcq:modificationOf -- rdfs:subPropertyOf --> owl:sameIndividualAs
dcq:modificationOf -- rdf:type --> owl:SymmetricProperty

then you can say
hdl:1271.1/5678 -- owl:modificationOf --> hdl:1271.1/5678;2

I didn't realise it, but from this thought experiment it's clear the history
system is a rather advanced use case for these ontology languages. Most of
the examples of ontology languages, like the wine ontology, assume the
universe described by the model is unchanging. 

There are probably some additional relationships we can define here, for
example we might want to relate dcq:replaces and dcq:replacedBy to
dcq:modificationOf as they are directed versions of this relation, but we'd
omit the owl:SymmetricProperty statement. Really it would be nice to have an
"upper-level" ontology that built these kind of primitives. 

Alternatively I think we could express this with ABC, using abc:precedes and
anc:follows as they do in the AMOL Vase Example 
http://metadata.net/harmony/JODI_Final.pdf
Of course, in a way this is cheating - we are just leaving it to ABC to
provide an ontology description rather than coming up with one by hand as
above. I think they only provide a description of ABC using RDFS, so it
would be an interesting exercise to map ABC into OWL. Any comments on this
Dan?

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/

> -----Original Message-----
> From: Jason Kinner [mailto:jason_kinner@dynamicdigitalmedia.com]
> Sent: 17 May 2003 17:11
> To: www-rdf-dspace
> Subject: RE: Representing distinct item states
> 
> 
> 
> This is an excellent point, originally brought up during the 
> first telcon to
> review the descriptive note.  My recommendation would be to 
> annotate each
> revision (state) node URI with a state identifier (version ID).
> 
> For example:
> 
> hdl:1271.1/5678;1 ----- dc:title -----> My Super Researck Paper
> 
> then:
> 
> hdl:1271.1/5678;2 ----- dc:title -----> My Super Research Paper
> 
> then:
> 
> hdl:1271.1/5678 ----- harmony:hasRealization ----> hdl:1271.1/5678;1
>                 ----- harmony:hasRealization ----> hdl:1271.1/5678;2
> hdl:1271.1/5678;1 ----- dcq:isReplacedBy -----> hdl:1271.1/5678;2
> hdl:1271.1/5678;2 ----- dcq:replaces -----> hdl:1271.1/5678;1
> 
> This is implicit in the current construction of state information for
> Harmony structures in the history system.  Like the bitstream 
> IDs that I
> reference so often, states are represented by numeric 
> identifiers that do
> not provide a navigable (in RDF, anyway) chain of revisions 
> for the metadata
> of a DSpace resource.  This maps to Rob's suggestion, but with
> hdl:1271.1/5678;1 for XXXXXX and hdl:1271.1/5678;2 for 
> YYYYYY.  There would
> also need to be a statement such as:
> 
> hdl:1271.1/5678 ----- owl:sameIndividualAs -----> 
> hdl:1271.1/5678;2 (the
> current revision)
> 
> This statement would be required for queries that (by 
> default?) would refer
> to the then-current state of the resource.  I wonder if this 
> complicates
> search significantly.  Back to the naming v. resolution debate, this
> technique would also make each revision of a resource resolvable, if
> supported by DSpace.
> 
> Regarding the scope of changes, this is typically addressed 
> by an explicit
> operation that the user invokes to annotate a new state.  For 
> example, in a
> document management system, I can check out/check in 
> different versions of
> an individual document, but the current version of the folder 
> (or compound
> document) remains the same.  When I "release" or "publish" a compound
> document, a snapshot of state is taken that can later be referenced
> explicitly.  This is similar to labeling a revision in source 
> code control.
> 
> I would suggest that keeping change contained to the nearest 
> object in the
> graph would be a good way to go for any object.  I believe 
> that adding or
> removing an Item to/from a Collection would need to be 
> modeled in History,
> but it is an open question whether the revision of the 
> Collection would be
> incremented in this case.
> 
> There is a larger question here about referencing any item in 
> DSpace and
> whether references always or sometimes point to the current 
> revision or to a
> specific revision.  Most commercial systems distinguish these 
> two kinds of
> references.
> 
> -Jason

Received on Monday, 19 May 2003 07:25:06 UTC