This is not quite correct; fixed fields* can be treated as just another
kind of property. Alternatively, fixed fields can be mapped to Classes.

For fixed fields that have a limited range of values, the values can be
represented as IRIs. For some fields mapping to class membership

For a fixed field that is either yes or no,  the value can be a boolean
data property, though membership of a class or its complement may be

For a fixed field that takes a numeric,  date,  or interval value, a data
property is  appropriate.

In regards to the original issue,  genre and form are logically distinct
concepts,  and it is not advisable to conflate the two.  Genre is an
attribute of the content of a work; form is most often an attribute of the
carrier or medium.

It is theoretically and practically better to model the two things
separately, then provide an underdetermined union for legacy data.


* I'm using "fixed field" to refer to the various logical parts of the
"Licensed to Kill" control fields, plus the appropriate parts of the
On Nov 11, 2015 1:52 PM, "Karen Coyle" <[log in to unmask]> wrote:

> Every IRI is the equivalent of a MARC fixed field -- that is, a coded,
> identified value.
> kc
> On 11/11/15 10:01 AM, J. McRee Elrod wrote:
>> The idea of "Electronic books" as a genre seems weird to me. As a rule of
>>> t=
>>> humb, shouldn't "genre" should be agnostic to physical/digital
>>> distinctions=
>>> ?
>> having this genre term is the easiest way to find what electronic
>> books are in a collection.  Not all ILS or patrons have the expertise
>> to search by a fixed field.  Also, will Bibframe have the equivalent
>> of MARC fixed fields?
>>     __       __   J. McRee (Mac) Elrod ([log in to unmask])
>>    {__  |   /     Special Libraries Cataloguing   HTTP://
>>    ___} |__ \__________________________________________________________
> --
> Karen Coyle
> [log in to unmask]
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600