Thanks Chris, this really increased my understanding of the CMA. I had
not separated the constraints on the persistence object (Fedora
hasModel) from the constraints and assertions about the domain object
(potentially rdf:type). Since these objects are not 1:1 the same thing
in our system, the CMA had previous seemed to sort of "flatten out" out
our domain model.
So my reservations are gone, but I still need to understand how the
whole thing might fit together.
skål,
Greg
Chris Wilper wrote:
> 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
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
