Karen,
I really don't see the issue with defining classes for these object.
You're saying that classes are not the same as structures. I agree.
What we see here is structure that indicates the presence of a class.
Let's take a class we agree is a class. Say, Agent, with subclasses
Person and Organization.
Within a metadata instance, an Agent may appear as
Creator
Name
Address
Email
i.e., a structure. But the fact that there is a structure in a metadata
record does not make the Agent = the structure.
So, in all cases there is only one kind of class. There is also
structures in application profiles. Those are two different things.
Regarding domains and ranges - specifying ranges in particular makes the
semantics of the properties more well-defined and more easily processed.
Not specifying is always allowed, but not always good practise.
I think the main issue in this case is that we would need to *introduce*
classes that are not explicit in RDA. I don't see a huge issue with
that, it's simply a bi-product of RDF modeling.
/Mikael
lör 2009-01-03 klockan 07:28 -0800 skrev Karen Coyle:
> 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]>
> >
>
>
>
--
<[log in to unmask]>
Varning! E-post till och från Sverige, eller som passerar servrar i
Sverige, avlyssnas av Försvarets Radioanstalt, FRA.
WARNING! E-mail to and from Sweden, or via servers in Sweden, is
monitored by the National Defence Radio Establishment.
|