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.


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]
>> 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 [log in to unmask]
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600

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