Discussion of Postcard Model

[azaroth42]

At: https://github.com/hybox/models/blob/master/notes/usecase.md

[azaroth42]

(Tagging: @anarchivist @no-reply @escowles @cmh2166 @tpendragon @mjgiarlo)

[tpendragon]

Two concerns, I'll put them in separate comments for discussion:

_:pc1 a pcdmw:Work ;
  rdfs:label "Postcard" ;
  edm:isRepresentationOf _:rwopc1 ;
  pcdm:hasMember _:front1, _:back1 ;
  pcdm:hasRelatedObject _:tn2 .

Postcard 1 has an image representation of the whole (a thumbnail) which is FileSet referenced via hasRelated Object.

_:front1 a pcdm:Object ;
  rdfs:label "Front of Postcard" ;
  pcdm:hasMember _:frontfs1 .

The front of postcard 1 has a FileSet which is representative of the whole object as a FileSet linked via pcdm:hasMember.

These two patterns seem conflicting, and work against the flexibility to have a collection of all the front pages of postcards, for instance. Do we need to pick a pattern (always hasRelatedObject? Is hasRelatedObject's semantics right for "representative fileset"? Is there something that should be on that FileSet to identify it as a representation...? Do we need a new predicate?)

[tpendragon]

Second concern:

Why is the front of the postcard a pcdm:Object and not a pcdmw:Work? In order to support the use case of "a collection of all the fronts of postcards", for instance, each layer of the hierarchy would have to look the same. I think they both act the same (or, at least, SHOULD), and the goal here seems to be to identify it as a Part - but it's only a Part in the context of its parent. Outside that context it's a standalone object - I think?

[azaroth42]

@tpendragon

Re related vs member, I agree. We're confusing representationOf and partOf ... leading to putting representations in hasRelatedObject when there are parts, and in hasMember when there aren't. If we had hasRepresentation separate from hasMember, we would solve the issue. And likely also Stefano and Adam W's concerns at the same time? Before pcdm-works this wasn't an issue, as representations would have gone directly in hasFile -- now there's an intervening Object subclass.

And re Object vs Work ... I was taking the approach that a Work is a bound or otherwise coherent thing. If the back of a postcard is a Work, then is the verso of page 214 of a book also a Work?
I'm happy to drop Work completely and just use Object, or to come to a clearer definition of when to use each.

[tpendragon]

If we had hasRepresentation separate from hasMember, we would solve the issue.

I'm leaning this way too.

is the verso of page 214 of a book also a Work?

When CC uses the "Part" stuff, it will be in Plum at least. And I think that's right.

[azaroth42]

If it's a Work, what's the difference between a Work and an Object? Can't we just use Object all the time?

[tpendragon]

If it's a Work, what's the difference between a Work and an Object? Can't we just use Object all the time?

Only if you let Works have Files.

[azaroth42]

Have Files with hasFile, or have FileSets with (hasMember/hasRelatedObject/hasRepresentation)?
But either way, Objects can have Files and FileSets, so we can still drop Work?

[tpendragon]

The reason there's a Work is because there are restrictions that don't exist on Objects (I think.) Of course, restrictions like that aren't present in RDF without something like SHACL, so we could always just say "if your Object hasFile something, and we're in Works land, we're not gonna do anything with it"

[azaroth42]

The reason there's a Work is because there are restrictions that don't exist on Objects

Okay, so those restrictions should define the difference :) What are the restrictions?

[tpendragon]

What are the restrictions?

I'll need backup from @escowles, @jcoyne, @mjgiarlo, @cmh2166 and company, but the one I know of is "Works can't hasFile"

[cmharlow]

Re related vs member:

Thinking that we are talking about hasRepresentation here as what relates a PCDM object to the digital representation, not as a possible inverse to edm:isRepresentationOf (which relates an object to a RWO or another resource to the repository object).

Are we not intimating in some way that [Object hasMember Fileset hasFile File] is that hasRepresentation relationship, made more complicated to support multiple versions of that file/representation? So...

_:pc1 a pcdmw:Work ;
  rdfs:label "Postcard" ;
  edm:isRepresentationOf _:rwopc1 ;
  pcdm:hasMember _:front1, _:back1, _:tn2 .

_:tn2 a pcdmw:Fileset ;
  rdfs:label "Postcard Thumbnail" ;
  a ??:Thumbnail (would we want to add some kinda type vocab here?) ;
  pcdm:hasFile <thumbnail.jpg> ;
  pcdm:hasFile <thumbnail.tiff> .

Differentiating hasRepresentation from hasMember, +1 (so not to use hasRelatedObject for odd outliers), but in the meantime, the thumbnail doesn't seem, to me, to fall under that 'is not a component part' portion of the hasRelatedObject comment. But I'm open to either.

Works/Objects comment forthcoming.

Hope that helps, and at least, doesn't hinder.

[cmharlow]

Looking at the comments here: https://github.com/projecthydra-labs/hydra-works/blob/master/lib/hydra/works/models/concerns/work_behavior.rb

Is it saying that pcdmw:Work could not pcdm:hasMember pcdm:Object that isn't a pcdmw:Fileset?

[escowles]

Agree with @tpendragon that _:front1 and _:back1 should be Works instead of Objects (probably all the Objects in the example should be Works). When we said at LDCX that we were using Part for convenience, I understood that to mean it was short for "Work that is part of another Work in some context". I also agree that the limitation of not having Files is an important limitation of Works that doesn't apply to Objects.

Two other things worth calling out:

1. _:pc1 pcdm:hasRelatedObject _:tn2 seems fine, but only if _:tn2 is a purpose-made thumbnail image (maybe a composite showing the front and back of the postcard in a single image?). But I would typically expect it to use one of the child objects as the preferred representation (see the mailing list discussion).
2. Instead of:

_:back1   pcdm:hasMember _:backfs1, _:backfs2 .

_:backfs1 a pcdmw:FileSet ;
  rdfs:label "Back of Postcard Image" ;
  pcdm:hasFile </backfs1/files/back.jp2>, </backfs1/files/back.jpg> .

_:backfs2 a pcdms:FileSet ;
  rdfs:label "Back of Postcard Transcription" ;
  pcdm:hasFile </backfs2/files/tei.xml>, </backfs2/files/transcription.txt> .

why not combine the FileSets:

_:back1   pcdm:hasMember _:backfs1 .

_:backfs1 a pcdmw:FileSet ;
  rdfs:label "Back of Postcard" ;
  pcdm:hasFile </backfs1/files/back.jp2>, </backfs1/files/back.jpg>,
    </backfs2/files/tei.xml>, </backfs2/files/transcription.txt> .

If we want a scenario that demonstrates two FileSets under a Work, maybe this would be better:

_:back1   pcdm:hasMember _:backfs1, _:backfs2 .

_:backfs1 a pcdmw:FileSet ;
  rdfs:label "Back of Postcard Image" ;
  dc:date "1999" ;
  pcdm:hasFile </backfs1/files/back.jpg> .

_:backfs2 a pcdms:FileSet ;
  rdfs:label "Back of Postcard Image" ;
  dc:date "2014" ;
  pcdm:hasFile </backfs2/files/back.jp2>, </backfs2/files/back.jpg>,
    </backfs2/files/tei.xml>, </backfs2/files/transcription.txt> .

[azaroth42]

probably all the Objects in the example should be Works

So there is no situation in which you would use pcdm:Object, only ever FileSet (for a bundle of files) and Work (for everything else)? If there's no other distinction between Object and Work, I don't see the point of having the subclass. Just have an application profile that says Don't use hasFile from Object if you're using FileSets.

Work: A work or intellectual entity, such as a book, film, dissertation, etc.

No one would ever use "Work" to describe a page of a book given this definition. A Chapter (e.g. a Range, subClassOf Object, not Work) is more of a Work than a physical page as it's the logical or textual structure that came from the intellectual/creative effort, not the printing of the physical Item.

I understood Work as "An Object that represents a coherent and complete intellectual entity which should be separately discoverable from other Works"

preferred representation

There isn't a predicate yet for the preferred representation though.

why not combine the FileSets:

Because .txt is derived from .tei, and FileSets have a single master and a single media type. The TEI is not derived from the Image.