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