Tom, once again we are at the difference between the formal language
of RDF and human language. RDF can define class however it wants,
since it is a formal language, but I'm really concerned about
communicating in normal human language, in which the term "class" has
a certain meaning. The use of "class" for structural semantic, as well
as conceptual semantic, meanings will cause confusion as we try to
take these concepts to a larger audience. It will be even more
confusing because some of the rdf uses of class will look very much
like the human language uses of "class," (a concept library people are
very familiar with) so people will assume that it has the same
meaning.

It's a very bad idea to redefine common terms. Then again, I worked on
a standards project where folks were so bent on not using common terms
that we ended up using words no one knows. I will try to add "rdf" in
front of any term when I use it that way.

Meanwhile, I think that Jon's suggestion is good. I'm not sure if RDA
dictates the order in the same way that AACR did, but I am sure that
library applications will have a fixed order. If we treat the
properties themselves as independent, then we can add more structure
in the application profiles and in the applications. I believe that
this means that we will not have rdf domains and rdf ranges in the
registered vocabulary definitions, although we do have properties and
sub-properties. I don't know if this affects the ability to use the
properties in a DCAP, but from my reading of the definition of rdf
property in the rdf concepts document, properties can exist without
rdf domains and ranges.

kc

On Sat, Jan 3, 2009 at 3:53 AM, Thomas Baker <[log in to unmask]> wrote:
> Mikael wrote:
>> > Classes as "aggregations" is a very common situation when translating
>> > from hierarchical structures to RDF. In IEEE LOM, we have
>> >
>> > Learning Object
>> >  Contribution
>> >    Role
>> >    Entity
>> >    Date
>> >
>> > i.e. a contribution to a learning object is a three-part aggregate.
>> >
>> > When translating this to RDF, it naturally comes out as n-ary. We
>> > introduce a class called lom:Contribution to hold the center node.
>> >
>> > There's really nothing strange with that. Think about the Book+Creator
>> > example:
>> >
>> > Resource
>> >  Creator
>> >    Name
>> >    E-mail
>> >    Address
>> >
>> > In this case, an Agent class is very natural for the middle node, with
>> > name, e-mail, address properties.
>
> On Fri, Jan 02, 2009 at 11:43:12AM -0800, Karen Coyle wrote:
>> Mikael, it makes sense if I willfully forget the meaning of the word
>> "class" and don't think about the classes that have sub-classes, which
>> make more sense to me. ;-) Actually, it makes the most sense if I
>> think of it as an abstract object, in OOP terms. But if we are to call
>> it class, I'll try to do that. It's a shame that there are two
>> logically different relationships that get the term "class."
>
> Mikael introduces a class called lom:Contribution in order,
> as he puts it, "to hold the center node" (see above).
> This short-hand way of putting things leaves out some detail
> which may be helpful to expand:
>
> A node is created, and that node is declared to be an instance
> of the class lom:Contribution by saying that the node has
> the rdf:type lom:Contribution:
>
>    :_    rdf:type  lom:Contribution
>
> So one does in fact create an abstract object (as you put it)
> -- the node.  But "class" is not being used for two logically
> different relationships.  The relationship linking the instance
> to a class is the property rdf:type.
>
> Tom
>
> --
> Tom Baker <[log in to unmask]>
>



-- 
--  ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
mo.: 510-435-8234
------------------------------------