Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instantiating Classes and/or Subclasses: patterns and issues #99

Open
kirkhess opened this issue Oct 19, 2022 · 0 comments
Open

Instantiating Classes and/or Subclasses: patterns and issues #99

kirkhess opened this issue Oct 19, 2022 · 0 comments

Comments

@kirkhess
Copy link
Contributor

Most BF classes have subclasses and there seems to be many examples where you use both the parent and the subclass. In some cases, the parent class is never used in practice and you only see subclasses used, which I think we can infer you should always use one of the subclasses but this isn't noted in the ontology.

Here's a few examples, this is not an exhaustive list of the situation:
class or subclass
bf:Title is very common and the subclass bf:VariantTitle is also very common. Both are used w/o a rdf:type so bf:Title and bf:VariantTitle. You don't see bf:Title with <rdf:type rdf:resource="bf:VariantTitle> at id.loc.gov. Note most VariantTitles have a literal property bf:variantType which sort of functions like additional subclass of bf:VariantTitle, which has 4 subclasses already (KeyTitle, ParallelTitle, AbbreviatedTitle, and the unused CollectiveTitle).

class or class + subclass
bf:Instance has 4 subclasses, but these do not cover every type of manifestation. So for Instances that are not print, electronic, tactile or archival, the resource is just a bf:instance, no rdf:type. You'll see bf:Instance, or bf:Instance with <rdf:type rdf:resource={Instance subclass}>. In practice you never see bf:Print at id.loc.gov.

either subclass or list
bf:Classification has 4 subclasses, but there is an editorial note "Any entry from the Classification Schemes vocabulary at ID may be used; all have been defined as a bf:Classification". However, I don't think you should use bf:Classification w/o a type now - the way it worked before is you used bf:Classification (no subclass) with a bf:source code pointing to the class scheme and now you probably do something similar to bf:Instance with a rdf:type rdf:resource={class scheme vocab}.

either class or subclass from list
bf:Note has no subclasses, but it has the similar note: "Any entry from the Note Types vocabulary at ID may be used; all have been defined as a bf:Note". bf:Note has a bf:noteType literal property which was used like bf:variantType but I think this has gone out of fashion in 2.2. Of course, bf:Note w/o a type is a pretty commonly mapped to 500 notes.

only subclasses
bf:digitalCharacteristic has a range of bf:DigitalCharacteristic. But you never instantiate the parent class (there's no mapping in either conversion), you always use one of the 9 subclasses. Also, you never see bf:DigitalCharacteristic<rdf:type rdf:resource="bf:FileSize">, its just bf:FileSize.

The rdfxml is somewhat specific to id.loc.gov serializations vs. Sinopia or ShareVDE. The main thing I was trying to point out was patterns like only subclasses or subclass from ontology/list, it would be helpful if there was a specific note that explained this pattern similar to the editorial note in bf:Classification so any consumers would know that you wouldn't ever see a bf:DigitalCharacteristic by itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant