Monday, May 11, 2015

Catalogers and Coders

Mandy Brown has a blog post highlighting The Real World of Technology by Ursula Franklin. As Brown states it, Franklin describes
holistic technologies and prescriptive technologies. In the former, a practitioner has control over an entire process, and frequently employs several skills along the way...By contrast, a prescriptive technology breaks a process down into steps, each of which can be undertaken by a different person, often with different expertise.
It's the artisan vs. Henry Ford's dis-empowered worker. As we know, there has been some recognition, especially in the Japanese factory models, that dis-empowered workers produce poorer quality goods with less efficiency. Brown has a certain riff on this, but what came immediately to my mind was the library catalog.

The library catalog is not a classic case of the assembly line, but it has the element of different workers being tasked with different aspects of an outcome, but no one responsible for the whole. We have (illogically, I say) separated the creation of the catalog data from the creation of the catalog.

In the era of card catalogs (and the book catalogs that preceded them), catalogers created the catalog. What they produced was what people used, directly. Catalogers decided the headings that would be the entry points to the catalog, and thus determined how access would take place. Catalogers wrote the actual display that the catalog user would see. Whether or not people would find things in the catalog was directly in the hands of the catalogs, and they could decide what would bring related entries within card-flipping distance of each other, and whether cross-references were needed.

The technology of the card catalog was the card. The technologist was the cataloger.

This is no longer the case. The technology of the catalog is now a selection of computer systems. Not only are catalogers not designing these systems, in most cases no one in libraries is doing so. This has created a strange and uncomfortable situation in the library profession. Cataloging is still based on rules created by a small number of professional bodies, mostly IFLA and some national libraries. IFLA is asking for comments on its latest edition of the International Cataloging Principles but those principles are not directly related to catalog technology. Some Western libraries are making use of or moving toward the rules created by the Joint Steering Committee for Resource Description and Access (RDA), which boasts of being "technology neutral." These two new-ish standards have nothing to say about the catalog itself, as if cataloging existed in some technological limbo.

Meanwhile, work goes on in bibliographic data arena with the development of the BIBFRAMEs, variations on a new data carrier for cataloging data. This latter work has nothing to say about how resources should be cataloged, and also has nothing to say about what services catalogs should perform, nor how they should make the data useful. It's philosophy is "whatever in, whatever out."

Meanwhile #2, library vendors create the systems that will use the machine-readable data that is created following cataloging rules that very carefully avoid any mention of functionality or technology. Are catalog users to be expected to perform left-anchored searches on headings? Keyword searches on whole records? Will the system provide facets that can be secondary limits on search results? What will be displayed to the user? What navigation will be possible? Who decides?

The code4lib community talks about getting catalogers and coders together, and wonders if catalogers should be taught to code. The problem, however, is not between coders and catalogers but is systemic in our profession. We have kept cataloging and computer technology separate, as if they aren't both absolutely necessary. One is the chassis, the other the engine, but nothing useful can come off the assembly line unless both are present in the design and the creation of the product.

It seems silly to have to say this, but you simply cannot design data and the systems that will use the data each in their own separate silo. This situation is so patently absurd that I am embarrassed to have to bring it up. Getting catalogers and coders together is not going to make a difference as long as they are trying to fit one group's round peg into the others' square hole. (Don't think about that metaphor too much.) We have to have a unified design, that's all there is to it.

What are the odds? *sigh*

Wednesday, April 29, 2015

The 50's were a long decade

Born in 1949, I grew up in the 50's. Those were the days of Gracie Allen ("Say goodnight, Gracie." "Goodnight, Gracie."), Lucille Ball, and Alice of the Honeymooners, for whom "To the moon, Alice!" did not mean that she could ever be astronaut. These were the models for the 1950's woman.

I was always bright and precocious. Before starting kindergarten I taught myself to read the Dick and Jane books that were being read to me. My parents didn't believe that I could read so they bought a book I had never seen and I read it to them. From then on my mother's mantra was, "Karen, no one is ever going to love you if you don't play dumb." Marilyn Monroe in Some Like it Hot. Not Myrna Loy in The Thin Man.

I wore glasses (from the age of 5) in a time when the chant "Men never make passes at girls who were glasses" was often heard.

Being smart and being female is still difficult in our culture. Esther Dyson, who for long has been one of the cultivators of deep thinking around technology, was introduced as "the most powerful woman in American business", to which she replied that she considered herself at least one of the most powerful people in her field. She's right. But being saddled with the "woman" category it means that she can be considered apart, not a threat to the status of any men who might otherwise be lessened by her success in "their" world.

I was fortunate to have a few high school teachers who appreciated intellect in a girl. (I was unfortunate to also have the local high school lech who paid girls A's to sit in the front of the class in mini-skirts but without panties.) It wasn't really until I hit college that the discrimination against smart women became intense. I can only imagine that it is because college professors see themselves as grooming the next generation of college professors, while high school teachers instead had the task of helping us learn what they had to teach, then leave. In my first semester at college I had one of those introductory courses that was held in an auditorium -- probably a history class of some sort. After class one day I walked with the professor toward his office and chatted with him about some idea that had come to me from his lecture. He was friendly and encouraging. At the next class meeting he began by saying: "After class last time, a young man presented me with a very interesting idea." He had not mistaken me at the time for a boy. This was a small private college and there was a dress code. I had long, flowing hair, wore makeup, and was wearing a dress. Instead, his memory turned me into a boy because it would have been impossible for him to have received a new and interesting idea from a girl. You can imagine how likely it would have been for him to become the mentor to a bright woman looking to pursue an academic career.

You may also be able to imagine how this statement made me disappear, not only in his eyes and the eyes of my classmates, who would never know that I was that "young man," but also in my own eyes. Psychologists call it "loss of significance" -- that your very being is denied; you are erased, post facto. I don't wonder that so many women suffer depression, because there is nothing more disorienting or more discouraging than having your own experience denied, pulled out from under you, and to be made invisible.

The stories, of course, abound; I couldn't begin to tell them all. This one, though, must be told: There was the boss who had hired me as the only woman holding a management position in the organization. He chuckled in surprise and disdain when I asked to be included in the meetings that he held with the otherwise-all-male management staff, which he had not thought to invite me to. He was even more surprised when I spoke up at the meetings. One day he called me into his office and praised me by saying "We're lucky to have found you. If you were a man we'd have to be paying you twice as much."

With great pain I realize that I experienced all of this from a position of great privilege, as a white, middle-class, educated American. I cannot imagine the prejudice of race or caste that others must live with, nor how that affects their sense of themselves as whole human beings.

I'm glad I went into librarianship, with all of its warts. I have spent my career surrounded by smart women. I got to create technology with women. I hope to do more of that. My main message here today, though, is this: if you can help a young woman understand her own worth, to appreciate her abilities, and to see being smart as a positive, please do, in whatever way you can. Whether it's encouragement, scholarships, or raising a daughter who never hears "no one will ever love you if don't play dumb." Let's make sure that the fifties are behind us.

Tuesday, April 21, 2015

Come in, no questions asked

by Eusebia Parrotto, Trento Public Library*

He is of an indeterminate age, somewhere between 40 and 55. He's wearing two heavy coats, one over the other, even though it's 75 degrees out today (shirt-sleeve weather) and a large backpack. He's been a regular in the library for a couple of months, from first thing in the morning until closing in the evening. He moves from the periodicals area along the hall to the garden on fair weather days. Sundays, when the library is closed, he is not far away, in the nearby park or on the pedestrian street just outside.

I run into him at the coffee vending machine. He asks me, somewhat hesitantly, if I have any change. I can see that he's missing most of his front teeth. I've got a euro in my hand, and I offer it to him. He takes it slowly, looks at it carefully, and is transformed. His face lights up with a huge smile, and like an excited child, but with a mere whisper of a voice, he says: "Wow!! A euro! Thanks!" I smile back at him, and I can see that he's trying to say something else but he can't, it tires him. I can smell the alcohol on his breath and I assume that's the reason for his lapse. He motions to me to wait while he tries to bring forth the sounds, the words. I do wait, watching. He lifts a hand to the center of his neck as if to push out the words, and he says, with great effort and slowly: "I don't speak well, I had an operation. Look." There is a long scar on his throat that goes from one ear to the other. I recognize what it is. He says again, "Wait, look" and pulls up his left sleeve to show me another scar along the inside of his forearm that splits in two just before his wrist. "I know what that is," I say.

Cancer of the throat. An incision is made from under the chin to arrive at the diseased tissue. They then reconstruct the excised portion using healthy tissue taken from the arm. That way the damaged area will recover, to the extent it can, its original functions.

With great effort and determination he tells me, giving me the signal to wait when he has to pause, that he was operated on nearly a year go, after three years in which he thought he had a stubborn toothache. When he couldn't take it any more he was taken to the emergency room and was admitted to hospital immediately. I tell him that he's speaking very clearly, and that he has to exercise his speech often to improve his ability to articulate words; it's a question of muscle tone and practice. I ask him if he is able to eat. I know that for many months, even years, after the operation you can only get down liquids and liquified foods. He replies "soups, mainly!" It will get better, I tell him.

His eyes shine with a bright light, he smiles at me, signals to me to wait. Swallows. Concentrates and continues his story, about a woman doctor friend, who he only discovered was a doctor after he got sick. He tells me some details about the operation; the radiation therapy. This is the second time that he has cheated death, he says. The first was when he fell and hit his head and was in a coma for fifteen days. "So now this, and it's the second time that I have been brought back from the brink." He says this with a smile, even a bit cocky, with punch. And then tears come to his eyes. He continues to smile, impishly, toothlessly. "I'm going to make it, you'll see. Right now I'm putting together the forms to get on disability, maybe that will help." "Let's hope it works out," I say as we part. And he replies: "No, not hope. You've got to believe."

The derelicts of the library. A few months back it was in all of the local papers. One student wrote a letter to the newspaper complaining that the presence of the homeless and the vagabonds profaned the grand temple of culture that is the library. Suddenly everyone had something to say on the matter; even those who had never even been to the library were upset about the derelicts there. They said it made them feel unsafe. Others told how it made them feel uncomfortable to come into the library and see them occupying the chairs all day long. Even when half of the chairs were free they were taking up the places of those who needed to study. Because you can't obviously mix with them.

I don't know how often the person I chatted with today had the occasion to speak to others about his illness. It's a terrible disease, painful, and it leaves one mutilated for life. Recovery from the operation is slow, over months, years. It's an infliction that leaves you with a deep fear even when you think you are cured. That man had such a desire to tell the story of his victory over the disease, his desire to live, his faith that never left him even in the darkest moments. I know this from the great light that radiated from his visage, and from his confident smile.

I don't know of any other place but standing at the vending machine of a library where such an encounter is possible between two worlds, two such distant worlds. I don't know where else there can be a simple conversation between two persons who, by rule or by necessity, occupy these social extremities; between one who lives on the margins of society and another who lives the good life; who enjoys the comforts of a home, a job, clean clothes and access to medical care. Not in other public places, which are open only to a defined segment of the population: consumers, clients, visitors to public offices. These are places where you are defined momentarily based on your social activities. Not in the street, or in the square, because there are the streets and squares that are frequented by them, and the others, well-maintained, that are for us. And if one of them ventures into our space he is surely not come to tell us his story, nor are we there to listen to it.

He is called a derelict, but this to me is the beauty of the public library. It is a living, breathing, cultural space that is at its best when it gathers in all of those beings who are kept outside the walls of civil society, in spite of the complexity and contradictions that implies.

The library is a place with stories; there are the stories running through the thousands of books in the library as well as the stories of the people who visit it. In the same way that we approach a new text with openness and trust, we can also be open and trusting as listeners. Doing so, we'll learn that the stories of others are not so different from our own; that the things that we care about in our lives, the important things, are the same for everyone. That they are us, perhaps a bit more free, a bit more suffering, with clothes somewhat older than our own.

Then I read this. It tells the story of the owner of a fast food restaurant who, having noticed that after closing someone was digging through the trash cans looking for something to eat. So she put a sign on store window, inviting the person to stop in one day and have a fresh meal, for free. The sign ends with: "No questions asked."

So this is what I want written on the front door of all libraries: "Come in, whoever you are. No questions asked."


*Translated and posted with permission. Original.

[Note: David Lankes tweeted (or re-tweeted, I don't remember) a link to Eusebia's blog, and I was immediately taken by it. She writes beautifully of the emotion of the public library. I will translate other posts as I can. And I would be happy to learn of other writers of this genre that we can encourage and publicize. - kc]

Friday, January 16, 2015

Real World Objects

I was asked a question about the meaning and import of the RDF concept of "Real World Object" (RWO) and didn't give a very good answer off the cuff. I'll try to make up for that here.

The concept of RWO comes out of the artificial intelligence (AI) community. Imagine that you are developing robots and other machines that must operate within the same world that you and I occupy. You have to find a way to "explain," in a machine-operational way, everything in our world: stairs and ramps, chairs and tables, the effect of gravity on a cup when you miss placing it on the table, the stars, love and loyalty (concepts are also objects in this view). The AI folks have actually set a goal to create such descriptions, which they call ontologies, for everything in the world; for every RWO.

You might consider this a conceit, or a folly, but that's the task they have set for themselves.

The original Scientific American article that described the semantic web used as its example intelligent 'bots that would manage your daily calendar and make appointments for you. This was far short of the AI "ontology of everything" but the result that matters to us now is that there have been AI principles baked into the development of RDF, including the concept of the RWO.

RWO isn't as mysterious as it may seem, and I can provide a simple example from our world. The MARC record for a book has the book as its RWO, and most of its data elements "speak" about the book. At the same time, we can say things about the MARC record, such as who originally created it, and who edited it last, and when. The book and the record are different things, different RWO's in an RDF view. That's not controversial, I would assume.

Our difficulties arise because in the past we didn't have a machine-actionable way to distinguish between those two "things": the book and the record. Each MARC record got an identifier, which identified the record. We've never had identifiers for the thing the record describes (although the ISBN sometimes works this way). It has always been safe to assume that the record was about the book, and what identified the book was the information in the record. So we obviously have a real world object, but we didn't give it its own identifier - because humans could read the text of the record and understand what it meant (most of the time or some of the time).

I'm not fully convinced that everything can be reduced to RWO/not-RWO, and so I'm not buying that is the only way to talk about our world and our data. It should be relatively easy, though, without getting into grand philosophical debates, to determine the difference between our metadata and the thing it describes. That "thing it describes" can be fuzzy in terms of the real world, such as when the spirit of Edgar Cayce speaks through a medium and writes a book. I don't want to have to discuss whether the spirit of Edgar Cayce is real or not. We can just say that "whoever authors the book is as real as it gets." So if we forget RWO in the RDF sense and just look sensibly at our data, I'm sure we can come to a practical agreement that allows both the metadata and the real world object to exist.

That doesn't resolve the problem of identifiers, however, and for machine-processing purposes we do need separate identifiers for our descriptions and what we are describing.* That's the problem we need to solve, and while we may go back and forth a bit on the best solution, the problem is tractable without resorting to philosophical confabulations.

* I think that the multi-level bibliographic descriptions like FRBR and BIBFRAME make this a bit more complex, but I haven't finished thinking about that, so will return if I have a clearer idea.

Saturday, January 10, 2015

This is what sexism looks like #2

Libraries, it seems, are in crisis, and many people are searching for answers. Someone I know posted a blog post pointing to community systems like Stack Overflow and Reddit as examples of how libraries could create "community." He especially pointed out the value of "gamification" - the ranking of responses by the community - as something libraries should consider. His approach was that it is "human nature" to want to gain points. "We are made this way: give us a contest and we all want to win." (The rest of the post and the comments went beyond this to the questions of what libraries should be today, etc.)

There were many (about 4 dozen, almost all men) comments on his blog (which I am not linking to, because I don't want this to be a "call out"). He emailed me asking for my opinion.

I responded only to his point about gamification, which was all I had time for, saying that in that area his post ignored an important gender issue. The competitive aspect was part of what makes those sites unfriendly to women.

I told him that there have been many studies of how children play, and they reveal some distinct differences between genders. Boys begin play by determining a set of rules that they will follow, and during play they may stop to enforce or discuss the rules. Girls begin to play with an unstructured understanding of the game, and, if problems arise during play, they work on a consensus. Boys games usually have points and winners. Girls' games are often without winners and are "taking turns" games. Turning libraries into a "winning" game could result in something like Reddit, where few women go, or if they do they are reluctant to participate.

And I said: "As a woman, I avoid the win/lose situations because, based on general social status (and definitely in the online society) I am already designated a loser. My position is pre-determined by my sex, so the game is not appealing."

I didn't post this to the site, just emailed it to the owner. It's good that I did not. The response from the blog owner was:
This is very interesting. But I need to see some proof.
Some proof. This is truly amazing. Search on Google Scholar for "games children gender differences" and you are overwhelmed with studies.

But it's even more amazing because none of the men who posted their ideas to the site were asked for proof. Their ideas are taken at face value. Of course, they didn't bring up issues of gender, class, or race in their responses, as if these are outside of the discussion of what libraries should be. And to bring them up is an "inconvenience" in the conversation, because the others do not want to hear it.

He also pointed me to a site that is "friendly to women." To that I replied that women decide what is "friendly to women."

I was invited to comment on the blog post, but it is now clear that my comments will not be welcome. In fact, I'd probably only get inundated with posts like "prove it." This does seem to be the response whenever a woman or minority points out an inconvenient truth.

Welcome to my world.

Monday, November 24, 2014

Multi-Entity Models.... Baker, Coyle, Petiya

Multi-Entity Models of Resource Description in the Semantic Web: A comparison of FRBR, RDA, and BIBFRAME
by Tom Baker, Karen Coyle, Sean Petiya
Published in: Library Hi Tech, v. 32, n. 4, 2014 pp 562-582 DOI:10.1108/LHT-08-2014-0081
Open Access Preprint

The above article was just published in Library hi Tech. However, because the article is a bit dense, as journal articles tend to be, here is a short description of the topic covered, plus a chance to reply to the article.

We now have a number of multi-level views of bibliographic data. There is the traditional "unit card" view, reflected in MARC, that treats all bibliographic data as a single unit. There is the FRBR four-level model that describes a single "real" item, and three levels of abstraction: manifestation, expression, and work. This is also the view taken by RDA, although employing a different set of properties to define instances of the FRBR classes. Then there is the BIBFRAME model, which has two bibliographic levels, work and instance, with the physical item as an annotation on the instance.

In support of these views we have three RDF-based vocabularies:

FRBRer (using OWL)
RDA (using RDFS)
BIBFRAME (using RDFS)

The vocabularies use a varying degree of specification. FRBRer is the most detailed and strict, using OWL to define cardinality, domains and ranges, and disjointness between classes and between properties. There are, however, no sub-classes or sub-properties. BIBFRAME properties all are defined in terms of domains (classes), and there are some sub-class and sub-property relationships. RDA has a single set of classes that are derived from the FRBR entities, and each property has the domain of a single class. RDA also has a parallel vocabulary that defines no class relationships; thus, no properties in that vocabulary result in a class entailment. [1]

As I talked about in the previous blog post on classes, the meaning of classes in RDF is often misunderstood, and that is just the beginning of the confusion that surrounds these new technologies. Recently, Bernard Vatant, who is a creator of the Linked Open Vocabularies site that does a statistical analysis of the existing linked open data vocabularies and how they relate to each other, said this on the LOV Google+ group:
"...it seems that many vocabularies in LOV are either built or used (or both) as constraint and validation vocabularies in closed worlds. Which means often in radical contradiction with their declared semantics."
What Vatant is saying here is that many vocabularies that he observes use RDF in the "wrong way." One of the common "wrong ways" is to interpret the axioms that you can define in RDFS or OWL the same way you would interpret them in, say, XSD, or in a relational database design. In fact, the action of the OWL rules (originally called "constraints," which seems to have contributed to the confusion, now called "axioms") can be entirely counter-intuitive to anyone whose view of data is not formed by something called "description logic (DL)."

A simple demonstration of this, which we use in the article, is the OWL axiom for "maximum cardinality." In a non-DL programming world, you often state that a certain element in your data is limited to the number of times it can be used, such as saying that in a MARC record you can have only one 100 (main author) field. The maximum cardinality of that field is therefore "1". In your non-DL environment, a data creation application will not let you create more than one 100 field; if an application receiving data encounters a record with more than one 100 field, it will signal an error.

The semantic web, in its DL mode, draws an entirely different conclusion. The semantic web has two key principles: open world, and non-unique name. Open world means that whatever the state of the data on the web today, it may be incomplete; there can be unknowns. Therefore, you may say that you MUST have a title for every book, but if a look at your data reveals a book without a title, then your book still has a title, it is just an unknown title. That's pretty startling, but what about that 100 field? You've said that there can only be one, so what happens if there are 2 or 3 or more of them for a book? That's no problem, says OWL: the rule is that there is only one, but the non-unique name rule says that for any "thing" there can be more than one name for it. So when an OWL program [2] encounters multiple author 100 fields, it concludes that these are all different names for the same one thing, as defined by the combination of the non-unique name assumption and the maximum cardinality rule: "There can only be one, so these three must really be different names for that one." It's a bit like Alice in Wonderland, but there's science behind it.

What you have in your database today is a closed world, where you define what is right and wrong; where you can enforce the rule that required elements absolutely HAVE TO be there; where the forbidden is not allowed to happen. The semantic web standards are designed for the open world of the web where no one has that kind of control. Think of it this way: what if you put a document onto the open web for anyone to read, but wanted to prevent anyone from linking to it? You can't. The links that others create are beyond your control. The semantic web was developed around the idea of a web (aka a giant graph) of data. You can put your data up there or not, but once it's there it is subject to the open functionality of the web. And the standards of RDFS and OWL, which are the current standards that one uses to define semantic web data, are designed specifically for that rather chaotic information ecosystem, where, as the third main principle of the semantic web states, "anyone can say anything about anything."

I have a lot of thoughts about this conflict between the open world of the semantic web and the needs for closed world controls over data; in particular whether it really makes sense to use the same technology for both, since there is such a strong incompatibility in underlying logic of these two premises. As Vatant implies, many people creating RDF data are doing so with their minds firmly set in closed world rules, such that the actual result of applying the axioms of OWL and RDF on this data on the open web will not yield the expected closed world results.

This is what Baker, Petiya and I address in our paper, as we create examples from FRBRer, RDA in RDF, and BIBFRAME. Some of the results there will probably surprise you. If you doubt our conclusions, visit the site http://lod-lam.slis.kent.edu/wemi-rdf/ that gives more information about the tests, the data and the test results.

[1] "Entailment" means that the property does not carry with it any "classness" that would thus indicate that the resource is an instance of that class.

[2] Programs that interpret the OWL axioms are called "reasoners". There are a number of different reasoner programs available that you can call from your software, such as Pellet, Hermit, and others built into software packages like TopBraid.

Tuesday, November 18, 2014

Classes in RDF

RDF allows one to define class relationships for things and concepts. The RDFS1.1 primer describes classes succinctly as:
Resources may be divided into groups called classes. The members of a class are known as instances of the class. Classes are themselves resources. They are often identified by IRIs and may be described using RDF properties. The rdf:type property may be used to state that a resource is an instance of a class.
This seems simple, but it is in fact one of the primary areas of confusion about RDF.

If you are not a programmer, you probably think of classes in terms of taxonomies -- genus, species, sub-species, etc. If you are a librarian you might think of classes in terms of classification, like Library of Congress or the Dewey Decimal System. In these, the class defines certain characteristics of the members of the class. Thus, with two classes, Pets and Veterinary science, you can have:
Pets
- dogs
- cats

Veterinary science
- dogs
- cats
In each of those, dogs and cats have different meaning because the class provides a context: either as pets, or information about them as treated in veterinary science.

For those familiar with XML, it has similar functionality because it makes use of nesting of data elements. In XML you can create something like this:
<drink>
    <lemonade>
        <price>$2.50</price>
        <amount>20</amount>
    </lemonade>
    <pop>
        <price>$1.50</price>
        <amount>10</amount>
    </pop>
</drink>
and it is clear which price goes with which type of drink, and that the bits directly under the <drink> level are all drinks, because that's what <drink> tells you.

Now you have to forget all of this in order to understand RDF, because RDF classes do not work like this at all. In RDF, the "classness" is not expressed hierarchically, with a class defining the elements that are subordinate to it. Instead it works in the opposite way: the descriptive elements in RDF (called "properties") are the ones that define the class of the thing being described. Properties carry the class information through a characteristic called the "domain" of the property. The domain of the property is a class, and when you use that property to describe something, you are saying that the "something" is an instance of that class. It's like building the taxonomy from the bottom up.

This only makes sense through examples. Here are a few:
1. "has child" is of domain "Parent".

If I say "X - has child - 'Fred'" then I have also said that X is a Parent because every thing that has a child is a Parent.

2. "has Worktitle" is of domain "Work"

If I say "Y - has Worktitle - 'Der Zauberberg'" then I have also said that Y is a Work because every thing that has a Worktitle is a Work.

In essence, X or Y is an identifier for something that is of unknown characteristics until it is described. What you say about X or Y is what defines it, and the classes put it in context. This may seem odd, but if you think of it in terms of descriptive metadata, your metadata describes the "thing in hand"; the "thing in hand" doesn't describe your metadata. 

Like in real life, any "thing" can have more than one context and therefore more than one class. X, the Parent, can also be an Employee (in the context of her work), a Driver (to the Department of Motor Vehicles), a Patient (to her doctor's office). The same identified entity can be an instance of any number of classes.
"has child" has domain "Parent"
"has licence" has domain "Driver"
"has doctor" has domain "Patient"

X - has child - "Fred"  = X is a Parent 
X - has license - "234566"  = X is a Driver
X - has doctor - URI:765876 = X is a Patient
Classes are defined in your RDF vocabulary, as as the domains of properties. The above statements require an application to look at the definition of the property in the vocabulary to determine whether it has a domain, and then to treat the subject, X, as an instance of the class described as the domain of the property. There is another way to provide the class as context in RDF - you can declare it explicitly in your instance data, rather than, or in addition to, having the class characteristics inherent in your descriptive properties when you create your metadata. The term used for this, based on the RDF standard, is "type," in that you are assigning a type to the "thing." For example, you could say:
X - is type - Parent
X - has child - "Fred"
This can be the same class as you would discern from the properties, or it could be an additional class. It is often used to simplify the programming needs of those working in RDF because it means the program does not have to query the vocabulary to determine the class of X. You see this, for example, in BIBFRAME data. The second line in this example gives two classes for this entity:
<http://bibframe.org/resources/FkP1398705387/8929207instance22>
a bf:Instance, bf:Monograph .

One thing that classes do not do, however, is to prevent your "thing" from being assigned the "wrong class." You can, however, define your vocabulary to make "wrong classes" apparent. To do this you define certain classes as disjoint, for example a class of "dead" would logically be disjoint from a class of "alive." Disjoint means that the same thing cannot be of both classes, either through the direct declaration of "type" or through the assignment of properties. Let's do an example:
"residence" has domain "Alive"
"cemetery plot location" has domain "Dead"
"Alive" is disjoint "Dead" (you can't be both alive and dead)

X - is type - "Alive"                                         (X is of class "Alive")
X - cemetery plot location - URI:9494747      (X is of class "Dead")
Nothing stops you from creating this contradiction, but some applications that try to use the data will be stumped because you've created something that, in RDF-speak, is logically inconsistent. What happens next is determined by how your application has been programmed to deal with such things. In some cases, the inconsistency will mean that you cannot fulfill the task the application was attempting. If you reach a decision point where "if Alive do A, if Dead do B" then your application may be stumped and unable to go on.

All of this is to be kept in mind for the next blog post, which talks about the effect of class definitions on bibliographic data in RDF.


Note: Multiple domains are treated in RDF as an AND (an intersection). Using a library-ish example, let's assume you want to define a note field that you can use for any of your bibliographic entities. For this example, we'll define entities Work, Person, Manifestation for ex:note. You define your note property something like:

ex:note
    a rdf:Property ;
    rdfs:label "Note"@en ;
    rdfs:domain ex:Work ;
    rdfs:domain ex:Person ;
    rdfs:domain ex:Manifestation ;
    rdfs:range rdfs:literal .

Any subject on which you use ex:note would be inferred to be, at the same time, Work and Person and Manifestation - which is manifestly illogical. There is not a way to express the rule: "This property CAN be used with these classes" in RDF. For that, you will need something that does not yet exist in RDF, but is being worked on in the W3C community, which is a set of rules that would allow you to validate property usage. You might also want see what schema.org has done for domain and range.