The most compelling case I can think of for title-as-resource is when you need to record the title source/type. Title source/type information is especially important with art related works, where the work may or may not have an explicit title and/or a work becomes better known by a title than the one the creator gave the work. Being able to record this contributes context to the description. VRA has a list of title types to address this and other cases [1].

This is more of applications problem, but… If we decide the above case isn’t important enough to create title resources, it seems we may want to use skos:prefLabel and skos:altLabels instead of dc:title in cases where we want to designate preferred titles. In the case of former titles [2], would these just become skos:altLabels? Nothing more specific?

[1] Page 35, http://www.loc.gov/standards/vracore/VRA_Core4_Element_Description.pdf 
[2] http://www.loc.gov/marc/bibliographic/bd247.html


-- 
Steven Folsom
Discovery Metadata Librarian
Cornell University Library

From: Robert Sanderson
Reply-To: Bibliographic Framework Transition Initiative Forum
Date: Sunday, April 26, 2015 at 2:33 PM
To: "[log in to unmask]"
Subject: Re: [BIBFRAME] Blank nodes vs. resources (redux)


You wouldn't even need hasTranslatedTitle, you could just do:

    resourceA dc:title "title"@en, "titre"@fr .


So the question (IMO) is what the use cases are that drive the title-as-resource model.  Why does the title need to be more than just a single, simple string associated with the right resource?  

If there are solid use cases, then document them, and create a resource. Then once you have a resource, following best practices says that it should have a URI and the issue is resolved.

Rob


On Sun, Apr 26, 2015 at 11:06 AM, Karen Coyle <[log in to unmask]> wrote:


On 4/26/15 9:48 AM, Robert Sanderson wrote:
-1

Giving identities to titles allows you to assert relationships between them, such as translationOf, abbreviationOf, and so forth.
As there has to be a title resource to allow for subtitle to be distinct from the main title, we should follow the "avoid blank nodes" best practice and give them real identity.

I see your point. Yet that means that EVERY string needs an identifier, and I have doubts about that as a practical solution. Not that there's much overhead in creating ids, but I don't see much utility in moving all strings to be subordinate to what amounts to a local identifier that only identifies one thing.(*)

To be sure the identity is to the title and not the string, so two items with the same title ("Complete works") get two different identities because they are titles to two different works, and the "coincidence" of being the same set of characters is not part of the meaning. Which means that the identity of the title is 1/1 with the resource, no? Is there any way that can be used? Such that ...

resourceA hasTitle "string"
resourceA hasTranslatedTitle "stringa"

etc.? This is how it is expressed in MARC, with all titles being titles of the resource. And this is also the meaning of dct:title.

kc
* I'm not sure what the status is of the title of an edition -- the work title is the same, but the expression and manifestation titles probably name different entities.




Unless titles really are just strings, and then we should use rdfs:label or dc:title with a string literal as the value, but in no possible world is a blank node the best option.

Rob


On Sun, Apr 26, 2015 at 8:27 AM, Karen Coyle <[log in to unmask]> wrote:
On 4/23/15 7:18 AM, Trail, Nate wrote:
Bf:Title being flattened out may be a mistake; I think it should really just a blank node, too.  I don’t much like blank nodes, but we need to group together the title properties.  Is there a use-case for  having all the bf:Works with the title “[Untitled] Photograph 1991.” point to a single resource someplace that returns you that string when you(r system) reference it?

Actually, I think that would be a mistake. Even though there are titles that are the same *string* they name a different thing. That would be like having a single identifier for everyone named Bill Jones. You would be identifying the string, not the resource whose title it is. Note that among published works there are ones with the same title -- but giving them the same identifier would imply that they are the same publication. They aren't.

I see no advantage to giving identifiers to titles. I think it makes sense to leave titles as strings to be read by humans and searched via keyword. They are text for human consumption. If we want to identify resources, a title alone won't do.

kc

--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305