You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: