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)

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