On Thu, 2005-02-10 at 14:43 +0000, Pete Johnston wrote:
> ... increasingly I do have more fundamental misgivings about the way we in DC
> have tended to approach this notion of "reuse".
>
> In the RDF/DC triple/statement based model, properties and classes are defined
> as more or less independent stand-alone entities. Yes, we assert relationships
> between resources (subproperty, subclass etc) but I can use a URIref like
> http://purl.org/dc/elements/1.1/title to denote the concept of "having a title"
> quite independently from that of having a subject, identifier etc etc etc.
>
> However, in XML-based applications like MODS, the component parts of the data
> structure do not have the same sort of independence/free-standing nature. MODS
> is an XML language or format, and the way individual components (XML elements,
> XML attributes) within MODS are interpreted is conditioned by their structural
> relationships with other components (containment relations, element/attribute
> relations etc) as defined by the rules of that XML language.
This is very true. When I have worked on formalizing the LOM RDF binding
I have used the trick of trying to bring the *whole* context into the
definition of each RDF property, to make sure I don't loose any of the
semantics.
For example, there is an element Language in LOM, used in three places:
In the General category, in the Metametadata category, and in the
Educational category. Now if I had done the mapping naively, this would
be just one URI. But in reality it is two:
* dc:language is used for the General and Metametadata occurences, as
the semantics matches dc:language precisely, even though it describes
the language for two different resources (the learning object and its
metadata, respectively)
* lom_edu:language is used in the Educational category, as the element
means a slightly different thing (the intended primary language of the
user).
This is a simple example, but in general when mapping from hierarchical
models to RDF, one must be certain that all semantics hidden in the
context (in this case, the categories above the element) is brought into
the property definition.
In theory, this could lead to properties of the form:
lom_annotation:entity_name
if that were any different than for example:
lom_lifecycle:contribute_entity_name
It so happens that the semantics are identical, but the properties are
applied to different resources (the learning object and the annotation,
respectively), so only one URI is needed...
It goes to show that the mapping must indeed be done on an
element-by-element basis, and with _thorough_ knowledge of the semantics
of _each_ element/category.
/Mikael
|