Hi Nate,


However, even better given the query optimization scenario would be:

    _:x bf:classification [ a bf:NlmClassification ; value "123" ]


Haven’t you gone here from deproliferating properties to proliferating classes?  If we did this, wouldn’t we also have to have these classes:

I have, yes :) But at the same time, getting rid of the string literals in scheme, and indeed, the scheme property all together.  So a net reduction in the model, and a net increase in simplicity and ease of querying.

and you’d still probably need the generic bf:Classification and a way to say what scheme it represents, as we develop or accept new mechanisms to organize new types of material that don’t rise yet to the level of having their own class?

I don't follow that, I'm afraid. Why wouldn't we (the community) give new Classification types their own subclass?