Hi Kåre and Greg,
Kåre said:
> The previous CMODEL object property actually used rdf:type
> as it's URL, but the new Content Model Architecture has opted
> for a different approach, using the property "hasModel" in
> the fedora vocabulary.
The decision not to use rdf:type in the CMA was deliberate,
and deserves some explanation.
Going into the CMA design process, we made a couple basic
assumptions:
1) Special Fedora objects should serve to identify and
describe content models.
2) All objects in Fedora should be describable via
a content model.
This means that even content model objects (our "classes")
are able to assert that they are in a content model.
You can see this in the demo content models -- each has
a "hasModel" relationship to the system-defined content
model for content models.
Modeling this in OWL (and thus using rdf:type instead of
"hasModel") was certainly possible, but it quickly put us
in OWL-Full territory because classes cannot be instances
("clinstances") otherwise.
So we decided (no pun intended) to use "hasModel" without
tying this core CMA relationship to OWL for now, noting
that it doesn't preclude a future move of declaring "hasModel"
as a subproperty of rdf:type. Note that regardless of such a
move, since content models themselves are instances, we'd
already be in OWL-Full.
Greg said:
> My suggestion would simply be to make your rdf:type
> statements in the RELS-EXT datastream and leave the
> contentModel field alone. The reason is that I see no
> semantic benefit to using the contentModel property of
> the Fedora object,
The "hasModel" relationship brings semantics to the party
that rdf:type doesn't -- it provides a standard way to
hook into a description of the "class" of Fedora Object
of which the referrer is a member. Among other useful
things, this information can be used to drive Fedora Object
validation all the way down to the bitstream format level.
> while on the other hand it imposes some limitations.
> First, your objects have single inheritance.
I'm not sure what you mean by inheritance here, but
I just want to clarify in case there's any confusion:
A) Fedora Objects can assert that they adhere to
multiple content models at once via multiple "hasModel"
relationships. The beta1 version of 3.0 was limited
in this regard.
B) As of 3.0, each content model is expected to be
self-contained. We have not defined or implemented
a "subclassing" feature whereby membership in one
content model implies membership in another.
> Second, we don't really know where the
> CMA is going in future releases, especially in terms
> of schema validation.
We hope to have laid a solid foundation without precluding
the innovation that needs to happen in this area, but this
is an ongoing process. Where the CMA goes in future
releases depends on exactly these types of discussions.
> So in my humble opinion it is
> premature to tie yourself to that architecture.
Hmmm.. I don't think it has to be an either/or thing.
It is typically the case that there is a 1:1 relationship between a
persisted Fedora object and a domain object, but we shouldn't
forget that they're different things. When modeling such domain
objects in RDF/OWL, it seems that rdf:type is the right way to
go. But "hasModel" speaks more to the persistent nature of
the thing as a Fedora object.
Cheers,
Chris
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
