Toby Inkster wrote:
* DCMI's hasFormat/isFormatOf. The two resources are "substantially the same [...] but in another format".In both these cases, the resources being described are different, but for many purposes it's useful to consider them identical. It would be good if OWL was able to be used to express something like this: [] is owl:equivRule of dc:hasFormat ; owl:implication [ owl:propertyOnOne dc:title ; owl:propertyOnAll ex:looseTitle ; owl:validity owl:Always ] . Which allowed us to reason:{ _:A dc:hasFormat _:A1 , _:A2 ; dc:title "Foo" . }=> { _:A ex:looseTitle "Foo" . _:A1 ex:looseTitle "Foo" . _:A2 ex:looseTitle "Foo" . } .
You can normally get around this by defining a higher abstraction level. So instead of looking at an audio track on a CD and an audio file, seeing that one is a different format of the other (e.g. the file was ripped from the CD) and that therefore they have certain properties in common (like a title) but not others (like a sample rate), you can just talk about a "track" as being abstracted from the versions. The abstract track will then hold the title while the more concrete objects hold properties like sample rate. This is basically what FRBR is all about. DC doesn't do this, they just talk about things on one level and then try to relate all the different things with properties like hasFormat. MusicBrainz does this as well with its "advanced relationships" - you chain up all the different tracks that are versions of one another. The plans for its new database schema are to introduce those higher-level abstractions. Translations are another case like this: instead of saying that one document is a translation of another you could relate both to a higher-level object that represents a language-neutral version of the document (but that doesn't always work nicely for translations; often it's important to know which language something was translated from). In my experience defining those abstractions is the most complicated task I came across in ontology design so far. Things can get very messy because there are tons of cases where your abstractions don't work nicely or they simply just don't represent the real world very well. But it's one way of dealing with partial equivalences. Regards, Simon
