Print

Print


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