Karen Coyle
Sat, 03 Jan 2009 07:28:34 -0800
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> > -- -- --- Karen Coyle / Digital Library Consultant kco...@kcoyle.net http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet mo.: 510-435-8234 ------------------------------------