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? Rob