-----BEGIN PGP SIGNED MESSAGE-----
Am 29.07.2014 00:21, schrieb Robert Sanderson:
>> Personally, I am in favor of investigating treating titles as string
>> literals. (And I mean all titles: constructed titles, regular
>> old-fashioned-this-is-the-title titles, abbreviated titles, spine titles,
>> key titles, added title page titles, etc.)
> _:Work bf:(constructed|abbreviated|spine|key|added|etc)Title "literal" .
> _:Work bf:title [ a bf:(Constructed|Abbreviated|Spine|Key|Added|Etc)Title ;
> bf:value "literal" ] .
> I prefer to multiply classes rather than predicates but the first way is
> much more straight forward if the only property of the Title resource is
> its value.
but can a ''work'' have a spine title?
For me, bf:Instances may have different kinds of titles as strings, although
I'm not sure we know enough about the universe to provide a fixed set of
string-valued properties covering all situations of "title" information
found on or in the resource.
Now the bf:work (think of the first french translation of The Adventures of
Tom Sawyer) has potentially several titles, one of them the spine title
of the instance above. However I would not consider this to be a spine title
of the bf:work. Rather any title we /associate/ with a bf:work should have
a justification - most of them are supplied because we have "instancial"
evidence of them (should we then provide the URI of the bf:instance as
"source"?), others are taken from elsewhere (encyclopedias, authority
files, scholarly literature, catalogues raisonnes - title authority data
probably would supply these too with source statements) and a third kind
are the titles supplied by cataloguers - adhoc translations, forms
usable for sorting or abbreviated titles for display. Perhaps these
should be kept together within the same bf:Title container.
I have to admit that I neither understand the intended meaning of
the titleSource property nor does the current list of properties
for bf:Title in < http://bibframe.org/vocab/Title.html > reflect
my expectation of "titles" as outlined above. Moreover most of these
attributes (part..., ...Type, ...) seem to address identification
issues of the bf:work or rather qualify the relation of this bf:work
to others. Of course these usually are evidenced by findings we
traditionally consider to be part of the "title" but probably won't
be able to develop their full potential when relocated into a
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----