Hi Kevin,

On Mon, Jul 28, 2014 at 1:53 PM, Kevin Ford <[log in to unmask]> wrote:

> I believe Rob is trying to underscore the fact that there are variable
> ways to record a Work's title (not to mention an Instance's) and, because
> there are variable ways to do it, the query becomes, well, ridiculous.

I didn't say ridiculous, but I did think it many times, and am glad that
you did :)

So, I believe Rob kicked off a thread that basically asked why are there
> two methods to capturing title information.[1] One way is to use a literal
> string and the other is to reference a bf:Title resource.  [... examples
> ...]

 The variability probably reflects a few things: trying to have it both
> ways so that implementers have the option; a misunderstanding or
> miscommunication about how multiple groups and individuals think about
> "titles;" a desire to accommodate old and new cataloging rules; and a level
> of parity with current cataloging practice.

The first is the dangerous one, and particularly so in a graph.  In my
opinion, the model should pick one. Whichever is the simplest case that
covers the use cases.  If that's string literals, fantastic.  If not, I
could live with blank nodes... just not both at once.

> 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.

However, that's a lot easier to say than it is to robustly test and robust
> testing is needed because titles clearly unearth a number of
> little-considered but real issues, such as a Work with multiple titles,

_:Work bf:title "literal 1" ;
  bf:title "literal 2" .

> each with translations or transliterations [2]

This becomes trickier, obviously.

It seems like you would need to have a resource to express
translation/transliteration relationships between.

_:Work bf:title _:title1 .

_:title1 a bf:AddedTitle ;
  bf:value "literal" ;
  bf:language lingvo:en ;
  bf:hasTranslation _:title2 .

_:title2 a bf:TranslatedTitle ;
  bf:value "littéral" ;
  bf:language lingvo:fr .

> and the need to capture the fact that a title was added by a cataloger

If this sort of provenance is needed at the title entry level, either the
assignment is reified (see also Simeon's examples in the Identifier thread,
and also bf:Annotation) or there would have to be a resource with an
assigner predicate.  I mean titleAssigner to follow current conventions ;)
[please please just assigner!]

_:title2 a bf:TranslatedTitle ;
  bf:value "littéral" ;
  bf:language lingvo:fr ;
  bf:translatedBy <> .

And bf:translatedBy should probably be rel:trl

> While the bf:Title construct exists as an attempt to address /some/ of
> those less common cases (such as a cataloger assigned titles), it remains
> problematic because it is hard to square that particular use case with
> existence of "bf:formDesignation" or "bf:titleAttribute," the definitions
> of which strongly suggest they are aspects of the Work, not a "title."

+1.  These should be taken off of title and pushed up to the Work.

> Which brings me to another point:  When we - as listserv participants -
> say "Title" are we always talking about the same thing?

To be clear, I mean the name of the Work.  Or its label. Its dc:title.

So, I think these last questions are the first ones we need to find
> agreement on.
> 1) Is a title an attribute or property of a Work or Instance?  Do you
> think of a "title" as synonymous with a Work (or Instance), that is, the
> thing you are describing?

A property (or relationship if the title needs to be Thingified)

>         OR
> 2) Is a title a type of Thing unto itself, one that can have its own
> identifier, and is related to but otherwise distinct from the Work or
> Instance you are describing? It is something that is associated with a Work
> but is not necessarily a property or attribute of the Work?  Though this is
> not only way to look at this, one wants to ask: Are titles re-usable?

It might be a thing unto itself, if it is important to capture information
regarding its provenance or other features.

For example, if it was important to capture that Rob Sanderson translated
the title, then there was a TranslationActivity that occured at a certain
point in time performed by Rob with the English title as input and the
French title as Output.

Overkill? I think so... but that's the implication of the translated title
use case where there's more information to be associated with the title
separately from the Work/Instance.

And yes, titles should be reusable if they're resources.


Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305