Consider using descriptionLevel instead of encodingLevel

[klngwll]

In bflc there is a property and Class for encodingLevel. Being able to grade descriptions is useful in many dealings with metadata. However a suggestion if it moves into the regular Bibframe vocabulary would be to instead add descriptionLevel (objectProperty) and DescriptionLevel (Class). Justification for this would be following the naming conventions of other properties used with the AdminMetadata Class. Also make it open for more broader use focusing on the descriptive content, not like the term encoding which I think for many implies something more technical oriented. SubClasses like EncodingLevel could of course still be used, if found useful to cater for different schemas like the MARC encoding level: http://id.loc.gov/vocabulary/menclvl.html

[kefo]

Also make it open for more broader use focusing on the descriptive content,

@klngwll Can you expand on this more, please? What types of information do you feel would be captured/recorded via a DescriptionLevel property/class (that differs from encoding level, obviously)? Examples?

[klngwll]

Most of all that it would give it a broader scope and more futureproof in general, detaching it from the MARC paradigm and courting to more entities being described from distributed sources.

In a more automated environment with the possibilites of machines to analyze metadata in different contexts it could be a valuable to cater for different schemes and sources (who is saying what in which context). An example of this is that we have seen is in the current work project where grading a Works fullness could be beneficial, but perhaps defined by another scheme not bound to something MARCy while still being able to distinguish between the two if both are needed.

That said of course it would be entirely possible to do the previous with the encodingLevel property and it might even be beyond the intention of it's original purpose, (my mind wanders off to PROV vocab here...). It's just that a descriptionLevel construct would be more consistent with the BF design and a bit more clearer what it is aiming for in a graph environment where we are talking about the description where it's level might be more bound to it's descriptionConventions and descriptionAuthentications and not the encoding of the actual record.

[kefo]

https://id.loc.gov/ontologies/bibframe.html#p_descriptionLevel