Adding Works extension ontology

[escowles]

Following discussion at the Hydra developers meeting in San Diego, this is an extension ontology which includes the new pcdm:Object subclasses that we've been using:

• Work
• FileSet (file and its derivatives)
• TopRange (a logical ordering of the parts of a Work)
• Range (parts of a TopRange)

This combines the classes that Hydra Works has been using to implement PCDM, and some notions from the IIIF Presentation API.

I would be particularly interested in hearing how well this lines up with Islandora and other PCDM implementations.

[azaroth42]

:+1: to the technical changes of this PR. Open issue as to documentation?

[escowles]

I've updated the PR with skos:closeMatch links to IIIF Range. And I've created a wiki page for documenting the expected usage: https://github.com/duraspace/pcdm/wiki/Works-Extension

[awoods]

:+1:

[jpstroop]

:+1:

[awoods]

@azaroth42, If you are good with this PR, please do the merge.

[DiegoPino]

@awoods and @escowles, just a quick question before you merge. Why are all works classes subclasses of http://pcdm.org/models#Object? Are ore:proxy's not used for example for ordering? And if not, could someone please add a quick RDF snippet so understand how a basic graph using this could be formed?

[ruebot]

Don't we need 8 thumbs now from committers? :smile:

[escowles]

@DiegoPino: these are all classes that would be ordered using ore:Proxy nodes. So if you have a book with 100 pages and 10 chapters, you would have:

• a Work for the book
• a FileSet for each page
• a TopRange for the chapters order
• a Range for each chapter
• a Proxy to order each page/FileSet (in the book/Work)
• a Proxy to order each chapter/Range (in the TopRange)

[DiegoPino]

@escowles, ok, and by which object property do you related Work with TopRange for example?

[escowles]

We have 10 committers. Doesn't that mean we need 6 to merge (a majority)?

I could four :+1: votes (mine is implied, @azaroth42, @awoods, @jpstroop), so either way I think we're short a couple.

[escowles]

@DiegoPino, you would use pcdm:hasRelatedObject to link from the Work to the TopRange (because it's an Object, but not a member). The Work would have the FileSets as its members, and the TopRange would have the Ranges as its members.

[ruebot]

@escowles I guess it depends on how we count? https://github.com/duraspace/pcdm/issues/8 was originally with 5 committers, and now that we have 10 committers the 3/5 would technically be 8/10. Unless 3/5 was just a simple majority, then, yeah, 6 thumbs :smile:

[escowles]

@ruebot, wait, wouldn't 3/5 be 6/10?

[ruebot]

@escowles yeah... I can COUNT!

[DiegoPino]

@escowles, ok, i sorta get the logic, but the same can be done using directly proxys?, sorry for being so hard, but i would love to see a rdf graph of this (including ldp stuff). I'm not voting (so you can just omit this) but i wonder how you plan to implement this (i hope not hardcoded) to be able to traverse a graph/maintain a work with this topology. It's just curiosity. Thanks!

[escowles]

@DiegoPino, I've created a drawing to illustrate how the pieces work together: https://docs.google.com/drawings/d/17BJ8H9JW76O8youNvMrsZ6I-iVGDGNP-2eR8dxFzSik/edit

The key reason that we can't just use more proxies is that we have sub-parts (like book chapters) that we want to order that don't correspond to the whole work or to the individual pages. We could just model the logical structure, but then getting from the book to the pages would require navigating the logical structure.

[DiegoPino]

@escowles, thanks! it's pretty complicated. Maybe it's just me but i would love to see more new object properties to make graph traversing easier, if we relay only on subclassing but keep the same predicates everywhere, making a generic approach on how to fetch this data gets more complicated. Thank you very much for taking the time to build that diagram.

[tpendragon]

@DiegoPino I think the theory has been that the inference and entailment logic necessary to handle using multiple predicates would be more complicated to implement than logic branches based on type. Certainly would be less expensive in LDP, though.

[tpendragon]

@escowles I think that's right, except the end proxies aren't the same node between the work and bottom ranges, right?

[DiegoPino]

@tpendragon right, assuming our ontologies are so open (no restrictions at all), but still a SPARQL query that depends only on your types is less efficient than one where you can guide the traversal by using an expected set of chained predicates. I'm good anyway. Thanks!

[awoods]

Regarding merge requirements, I would suggest:

• One implementer and 3 other committers agreeing to a PR is sufficient for merge... assuming no committer vetos.

[ruebot]

@awoods I'm good with that.

[azaroth42]

As this discussion will get lost when the PR is merged, can someone take on capturing it in the wiki please?

[awoods]

Wiki has been updated... but I am happy to rollback the update if there is not agreement on the proposed policy.

[kestlund]

:+1: to the PR :+1: to updating the voting policy to fewer votes noting lack of vetos, but I also wonder if we should implement a time frame; e.g. no :-1: 's within 5 days

• catching up as a weekend PCDM committer

[awoods]

Shall we define the timeframe as 5 days after the third +1?

[no-reply]

@tpendragon said:

I think the theory has been that the inference and entailment logic necessary to handle using multiple predicates would be more complicated to implement than logic branches based on type. Certainly would be less expensive in LDP, though.

I'm not sure I follow this. @DiegoPino's point that query and traversal are easier with unique predicates seems correct to me. Can you unpack where the entailment logic becomes an issue?

That said, I'll always be :-1: on minting predicates only to differentiate domain/range. If we can articulate how, e.g., works:hasRange would be a genuinely different relation from pcdm:hasMember, then that's worth discussing. Otherwise, :+1: for these changes as-is.

[azaroth42]

That said, I'll always be :-1: on minting predicates only to differentiate domain/range.

Agreed! That way leads to madness like hasISBNIdentifierForArchivalMaterialNumber

[escowles]

Ready to merge? I see four +1s (@azaroth42, @ruebot @awoods and @kestlund) and no -1s, with more than 7 days elapsed since the last change/discussion.

[ruebot]

I think we're good to go.

clicks the green merge button