Print

Print


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