Thomas Baker
Sat, 03 Jan 2009 03:53:25 -0800
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 <tba...@tbaker.de>