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