search

hybox / models

Data Modeling repository for HyBox (ontologies, vocabularies, best practices, requirements, etc)
Apache License 2.0
5 stars 3 forks source link

Use Predicates instead of Use Classes? #43

Open azaroth42 opened 8 years ago

azaroth42 commented 8 years ago

Talked through the current postcard model with @jcoyne and @mjgiarlo this morning, and this came from that discussion.

It would be easier to use predicates for the relationship between Object and FileSet, and between FileSet and Files than to look for classes on the child resource.

In particular, the clinching use case was an Object with two FileSets, one for Image depiction and one for TEI transcription. The question came up: How do I know that I can display the TEI file (or likely a pre-processed derivative) as the text of the Object? With Use, the TEI file would need to be both OriginalFile and ExtractedText, and all derivatives would be ExtractedText. So the processing requirement would be:

For each FileSet,
  For each File,
    If the File is a use:ExtractedText,
      Record it
Pick one of the ExtractedTexts to render

It seemed easier to link from the Object to the TEI FileSet with a relationship, rather than filtering like this. Similarly, filtering the Files for the OriginalFile rather than following a "hasOriginalFile" relationship seemed significantly easier.

So, the proposal is to continue with a single container for Files (and FileSets, issue forthcoming) and also add a relationship from the parent to the child.

tpendragon commented 8 years ago

Isn't this contrary to #44? Or are you proposing both hasFileSet and hasOriginalFile statements?

azaroth42 commented 8 years ago

Both. hasFileSet / hasFile for the direct containers to look after the content, and then additional predicates to clarify use within the parent.

escowles commented 8 years ago

So you would use both hasFile and, e.g., hasThumbnail? When you wanted a thumbnail, you'd use the hasThumbnail predicate, but if you didn't care about the type of File, you'd just use hasFile?

That seems like good functionality on the read side of things, but adds to the overhead on the create side of things. I'm fine with that tradeoff (since I expect most repositories get a lot more reads than writes), but it's worth noting that it's a tradeoff.

azaroth42 commented 8 years ago

Agree that it's a tradeoff. Hopefully the number of changes to these would be low, and possible to do after the initial load. The POST would go to the hasFile container, then a PATCH on the object to add the hasThumbnail (or whatever) predicate. And yes, if it's just a file, then no subsequent PATCH.

tpendragon commented 8 years ago

Mmph. I didn't even think about the extra PATCH. That would be pretty unpleasant.