Remove the Work class from the Works extension

[escowles]

The works extension includes a Work class for representing the top level of an item (e.g., an entire book as opposed to its pages).

Discussion of the Work class focused on problems, such as an item being a Work in its own right, but also part of another Work (e.g., a page of a book, which is a map that might be included in a map collection). The consensus was that because of the different contexts, it didn't make sense to label something as a Work, and it would be better to just make everything an Object and use context to figure out whether something was an independent entity or part of another Object.

Should we remove the Work class from the Works extension and/or PCDM 2.0?

See #53 for preliminary discussion.

[acoburn]

It may be worthwhile to consider this in the context of ore:ResourceMaps, which are used precisely to describe aggregations such as this (i.e. one ReM may describe a particular page of a book, while another ReM describes the graph consisting of the entire book.

[tpendragon]

I'm 👍 for removing the Work class.

@acoburn We talked about this some, but I'm not convinced that's what a ResourceMap is. It "describes aggregations", but by grouping statements that have the subject of the aggregation, and I certainly don't think they describe different graphs. Can you build an example of what you're thinking?

[azaroth42]

👍 to remove, and 👎 to ResourceMaps. ResourceMaps are the information resources that describe aggregations -- they're essentially the serialization with its own metadata and cannot exist without an aggregation. They're (mea culpa) a librarian view on the importance of a "record" when we didn't really understand how the global graph was going to pan out.

[cmharlow]

@azaroth42 - that explains a lot. thanks for clarifying!

[DiegoPino]

@azaroth42 now you got me confused. So are you removing ReM from the ORE specs? Without ReM how do you known where one aggregation starts and ends? In a semantic point of view, they still make sense to me, but if they will be removed from ORE would be good to know.

[azaroth42]

No, there's no process to update ORE. Not sure what you mean by start and end? In terms of membership, they start with the first (cough, actually any random) aggregated resource and end with the last (cough, any other random) aggregated resource. Resource Maps are just a not-very-concise bounded description or hack at implementing a named graph, circa 2006.

[DiegoPino]

@azaroth42 i was constantly interpreting ReM as named graphs(they have unique URL and are defined as a subsclass of rdfs:Graph). Well, i was mistaken!

[tpendragon]

Thanks for the clarification, @azaroth42

[cmharlow]

+1 removing hw:Work / not including it in PCDM (without much more use casing, discussion). I agree that PCDM can figure out contextually what it needs, when it needs it, about the whole / part information captured now with hw:Work if we just keep pcdm:Object. I have also wondered if hw:Work was more about capturing what is the primary discovery resource in the repository than any idea of Work completeness (just a thought, and probably an incorrect one).

But more for me, I think we aren't using hw:Work with a firm enough definition to make it really meaningful - which, no fault there, pinning down 'completeness' is often hard + arbitrary, especially with the wide variety of materials we see in digital repositories. Doubly especially with hw:Work often sitting at the intersection of digital object structure + intellectual... conceptualizations?.

IMHO, I think implementations can decide on linking or typing pcdm:Object with other ontologies for the contextual descriptive needs in play for the repository or the resource types' domain (domains here == Musical Scores, or Paintings, or Newspaper Articles, etc.). From that, we can approach the other possible uses for capturing Work / Part separation that fall in bibliographic or cultural heritage resource descriptive practices (and avoid getting PCDM via Hydra-Works brought into those discussions, or worse, discussed with a different understanding of Work attached to it).

[acoburn]

w/r/t ResourceMaps, I do not see them as an ideal way to express and describe an aggregation of resources. If I were to invent a vocabulary, I'd see no problem with putting descriptive metadata directly on the aggregation-like resource.

That said, pcdm:Object < ore:Aggregation and pcdm:hasMember < ore:aggregates, and so by RDFS entailment, any pcdm:Object is also an ore:Aggregation. And furthermore, according to the ORE spec, any ore:Aggregation MUST have a corresponding ore:ResourceMap.

And as much as I find ResourceMaps unnecessary, I find that simply ignoring a spec to be even worse and not something I can recommend to my institution. To put this another way, if PCDM is not interested in following the semantics of ORE, why doesn't it just use DC: pcdm:Object < dcmi:Collection and pdcm:hasMember < dcterms:hasPart?

[cmharlow]

Heya @acoburn - I completely feel what you're saying here:

And as much as I find ResourceMaps unnecessary, I find that simply ignoring a spec to be even worse and not something I can recommend to my institution.

Has this been brought up before in PCDM discussions, does anyone know? If so, is this a good time to bring this thread back up / if not, should we start that discussion thread and figure out if 1. we want to start using ResourceMaps or 2. really push ORE to stop using Resource Maps or 3. we stop subclassing ORE ?

Also, Aaron - any hesitancy against dropping specifically the Work construct from HydraWorks? I apologize if I'm missing the point with your previous discussions of Resource Maps in the context of this question - I'm still wrapping my head around all this. Thank you for your input!

[scossu]

👍 to dropping Works.

[acoburn]

@cmh2166 I have no particular opinion on Works: I don't use it and have no plans to use it. What I do need is a mechanism for identifying "Top-Level" resources -- the role that I understand Works to fill. For that, I plan to use ResourceMaps (others may have different approaches here -- OWA). If y'all want to drop Works, it sure sounds like a good idea to me, but again, I have no real opinion on it.

[escowles]

👍 to dropping the Work class.

Though if the relationship to ORE and our lack of ResourceMaps is troubling to people, then we should address it. I am not hearing any support for requiring ResourceMaps, and it sounds like ORE isn't going to be updated to make them optional. So I think documenting our decision not to include them in PCDM would be best way forward. I think that would look something like:

• PCDM classes/predicates are mostly subclasses of ORE classes/predicates
• ORE requires ResourceMaps, but they aren't mentioned in PCDM
• We found the ORE Aggregations and Proxies to be useful, so we used them, but ResourceMaps didn't seem useful to us.
• If you want to use ResourceMaps (either to conform to the ORE spec or because you find them useful) go ahead, but you don't need them for PCDM.