Mikael Nilsson
Sat, 03 Jan 2009 08:01:33 -0800
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 <tba...@tbaker.de> 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 <tba...@tbaker.de> > > > > > -- <mik...@nilsson.name> 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.