Hi Karen,
Yes, the query in the UC doc is one of the many, many possible ways to
encode a title using the current vocabulary.
There is, in English rather than SPARQL:
* Work with bf:title ( http://bibframe.org/vocab/title.html )
* Instance with bf:title
* Work with bf:titleStatement (
http://bibframe.org/vocab/titleStatement.html )
* Instance with bf:titleStatement
* Work with bf:label ( http://bibframe.org/vocab/label.html ) N.B. look at
the example here
* Instance with bf:label
* Work with bf:workTitle of a bf:Title
* Instance with bf:instanceTitle of a bf:Title
* Work with bf:titleVariation of a bf:Title
* Instance with bf:titleVariation of a bf:Title
* Instance with bf:abbreviatedTitle of a bf:Title
* Instance with bf:keyTitle of a bf:Title
* Multiplied by two ways to get from Work to Instance (bf:hasInstance,
bf:instanceOf)
* Multiplied by the matrix of title-string-holding attributes of bf:Title:
* bf:Title uses bf:titleValue alone
* bf:Title uses bf:titleValue and bf:subtitle
* ...plus bf:partTitle, bf:partNumber, bf:titleAttribute,
bf:titleQualifier
* bf:label could also be used instead of bf:titleValue
And this without translation, transliteration or the other complexities
introduced in the thread's discussion.
Notes:
* Presumably one could have a HeldItem/HeldMaterial with a title different
from its Instance, if someone physically modified a particular copy. This
isn't in the model at the moment, but thinking in an archival way rather
than library way I don't see why not. I leave this as an exercise for the
reader.
Rob
On Mon, Jul 28, 2014 at 3:31 PM, Karen Coyle <[log in to unmask]> wrote:
> Because I have trouble thinking about these things in the abstract, I made
> a small file with all of the BF properties that have the domain of bf:Title:
>
> http://kcoyle.net/temp/BFtitle.ttl
>
> That shows me that all of the properties have the range rdfs:literal.
>
> Note that the bf:title property is not among these -- it is defined as:
>
> <http://bibframe.org/vocab/title>
> a rdf:Property ;
> rdfs:comment "Word, character, or group of words and/or characters
> that is a name given to a resource" ;
> rdfs:label "Title" ;
> rdfs:range rdfs:Literal .
>
> Because rdfs:domain is not defined, it defaults to rdf:Resource. In the
> recent examples that I have seen, the literal bf:title repeats the literal
> values associated with the title types that take URI values (fragments
> below):
>
> bf:title "The adventures of Tom Sawyer", "adventures of Tom
> Sawyer"@x-bf-sortable ;
> bf:workTitle <http://bibframe.org/resources/Ahx1405278232/
> 1706459title7> ;
> a bf:Text, bf:Work .
> ...
> <http://bibframe.org/resources/Ahx1405278232/1706459title7>
>
> bf:titleValue "The adventures of Tom Sawyer" ;
> a bf:Title .
>
>
> Kevin and Rob, this appears to match the query in the use cases document:
>
>
> SELECT ?work ?inst ?lib
> WHERE {
> ?work bf:title "Phantom Tollbooth"
> ?inst bf:instanceOf ?work
>
> for a simple title search.
>
> Therefore, is it the case that a full title search would need to include
>
>
> SELECT ?work ?inst ?lib
> WHERE {
> ?work bf:title "Phantom Tollbooth"
> ?inst bf:instanceOf ?work
> ....
>
> as well as a query using
>
> ?work rdf:type bf:Title
>
> ?
>
> kc
>
>
>
> On 7/28/14, 2:40 PM, Karen Coyle wrote:
>
>> On 7/28/14, 1:53 PM, Kevin Ford 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.
>>>
>>
>> Kevin, yes, I agree, although it gets even more ridiculous when the work
>> title is a URI, which then must be resolved to a string (except when the
>> work title is a string). The question, then, is what is the use case for
>> title as URI?
>>
>>>
>>>
>>> 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."
>>> Since these properties are associated with a bf:Title resource (and a
>>> bf:Title resource is distinct from a Work or Instance), they raise
>>> vocabular/modelling questions. And, because they have corollaries in MARC,
>>> they also evoke current MARC-cataloging practice.
>>>
>>
>> I'm not clear on what you mean here by the bf:Title construct. There is a
>> bf:Title class, which could help matters in some circumstances, since one
>> can search using rdf:type and therefore retrieve all predicates that are
>> sub-classes of bf:Title. At that point, however, the next step in the
>> SPARQL query would need to be the same for all titles to work easily. Not
>> knowing up front if the title will be a URI or a string could make a
>> difference in formulating a query.
>>
>>
>>> 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?
>>>
>>> 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 seems to me that the question is a bit different (or perhaps there is
>> yet another question) which is:
>>
>> 3) Do we need say things about the title? If so, it must be a "thing"
>> with a URI. If not, then it can be a literal string.
>>
>> And an even bigger question:
>>
>> 4) Is there any of our data that can be a literal string, or must there
>> always be the option of saying something about the data itself? If so, then
>> our vocabulary becomes quite complex, and that will be evident in the
>> searches that can be run against it.
>>
>> I wonder if we aren't imposing our closed world needs (e.g. the innards
>> of library systems, and of the library-to-library catalog data exchange)
>> with what will instead work best in a more open environment. If I wish to
>> link my authors or titles with, say, Wikipedia, what are my "data about
>> data" needs? Are they as detailed as the ones I would use to make decisions
>> about copy cataloging?
>>
>> kc
>>
>>
>>> I don't think there are any right or wrong answers to the above
>>> questions. I'm interested in gaining a better understanding where everyone
>>> is coming from, which I hope will then be an indicator about which way to
>>> take this thread. And I certainly do not see the above as precluding one
>>> of the two possibilities as they currently exist, nor do I find this
>>> approach to be a replacement for use cases. I'm just trying to determine
>>> if there is an underlying point-of-view issue here.
>>>
>>> [ For my answer: I see it as (1). I view titles as attributes or
>>> properties of Works and Instances, not things unto themselves.]
>>>
>>> Yours,
>>> Kevin
>>>
>>> [1] http://listserv.loc.gov/cgi-bin/wa?A2=ind1407&L=bibframe&T=0&P=21183
>>> [2] http://listserv.loc.gov/cgi-bin/wa?A2=ind1407&L=bibframe&T=0&P=22684
>>>
>>>
>>>
>>>
>>> On 07/28/2014 01:38 PM, Karen Coyle wrote:
>>>
>>>> Rob, I'm not sure that the use cases document is up to date with the
>>>> current state of BF. As I stated before, here is an actual title "entry"
>>>> from a recently converted MARC->BF:
>>>>
>>>>
>>>> bf:instanceTitle
>>>> <http://bibframe.org/resources/Ahx1405278232/1706459title33>
>>>>
>>>> <http://bibframe.org/resources/Ahx1405278232/1706459title33>
>>>>
>>>> bf:titleValue "The adventures of Tom Sawyer" ;
>>>>
>>>> a bf:Title .
>>>>
>>>> bf:title exists, as do bf:titleVariation, bf:titleType, and
>>>> bf:titleStatement. I believe that these would change the SPARQL query.
>>>> If you'd like, I can create a small test set.
>>>>
>>>> kc
>>>>
>>>> On 7/28/14, 10:26 AM, Robert Sanderson wrote:
>>>>
>>>>> (Was alleys, before that titles)
>>>>>
>>>>> From the use cases document:
>>>>>
>>>>> SELECT ?work ?inst ?lib
>>>>> WHERE {
>>>>> ?work bf:title "Phantom Tollbooth"
>>>>> ?inst bf:instanceOf ?work
>>>>> ...
>>>>>
>>>>>
>>>>> I think this needs to be something like...
>>>>>
>>>>> SELECT ?work ?inst ?lib
>>>>> WHERE {
>>>>> { ?work bf:title "Phantom Tollbooth" }
>>>>> UNION
>>>>> { ?work bf:titleStatement "Phantom Tollbooth" }
>>>>> UNION
>>>>> { ?work bf:label "Phantom Tollbooth" }
>>>>> UNION
>>>>> {
>>>>> { ?work bf:workTitle ?title }
>>>>> UNION
>>>>> { ?work bf:titleVariation ?title }
>>>>> ?title bf:titleValue "Phantom Tollbooth" }
>>>>> UNION
>>>>> {
>>>>> { ?work bf:hasInstance ?inst }
>>>>> UNION
>>>>> { ?inst bf:instanceOf ?work}
>>>>> UNION
>>>>> { ?inst bf:label "Phantom Tollbooth" }
>>>>> UNION
>>>>> {
>>>>> { ?inst bf:instanceTitle ?title }
>>>>> UNION
>>>>> { ?inst bf:titleVariation ?title }
>>>>> ?title bf:titleValue "Phantom Tollbooth"
>>>>> }
>>>>> ...
>>>>>
>>>>> Yes? :(
>>>>>
>>>>> And this is a simple case without punctuation, sub-titles, etc.
>>>>>
>>>>> Rob
>>>>>
>>>>> On Mon, Jul 28, 2014 at 9:53 AM, [log in to unmask]
>>>>> <mailto:[log in to unmask]> <[log in to unmask]
>>>>> <mailto:[log in to unmask]>> wrote:
>>>>>
>>>>> I have had that feeling all through these discussions. At:
>>>>>
>>>>> http://bibframe.org/documentation/bibframe-usecases
>>>>>
>>>>> only six out of fifteen use cases mention library patrons (by my
>>>>> count), so I am inclined to think that the answer to that second
>>>>> question may in fact be: library catalogers and their colleagues.
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Karen Coyle
>>>> [log in to unmask] http://kcoyle.net
>>>> m: 1-510-435-8234
>>>> skype: kcoylenet
>>>>
>>>>
>>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305
