-----BEGIN PGP SIGNED MESSAGE-----
Am 16.05.2015 um 00:36 schrieb Karen Coyle:
>>> whatever property you have that takes a literal for the title (bf:title,
>>> bf:instanceTitle, bf:keyTitle... etc.) can be used in any triple s, bf:x, o.
>>> although you may define bf:title to have a range of, say, bf:Title, some
>>> property has to be the property for the literal string of that title. And th
>>> property can be used in any triple s, bf:x, o. So you cannot prevent people
>>> (using RDF) from saying
>>> <http://bibframe.example.com/workX> bf:x “Lord of the Flies” .
>> which, assuming bf:x would be set up as having a domain of bf:Title, would
>> by inference turn <http://bibframe.example.com/workX> an instance of bf:Title
> Thomas, thanks. I obviously wasn't thinking about inferencing nor assuming tha
> bf:x would have a domain of bf:Title. I haven't yet seen much to indicate that
> inferencing will be a big (or even small) part of library or bibliographic dat
> I note that, at least in the examples I have seen, BIBFRAME explicitly states
> rdf:type on subjects rather than relying on inferencing. (This seems to be a
> common practice in RDF applications.) The main practical use case I see for
> domains is in searching ("do this search on every property of class x").
> My thinking was that bf:x would have a general domain like rdfs:Resource, whic
> would allow it to be used without incurring a specific inference on the subjec
> This makes it similar to rdfs:label, but a label that would only apply to
> titles, thus it would be searchable specifically as a title. Whether or not th
> is practical depends on a lot of factors.
well, the class of title-bearing resources would be the union of bf:Work and
Your "solution" (which I still consider a solution without quotes) gave me the
insight that it might be more preferable to let users "violate" class
distinctions than to have properties with several value types (or variantly
named properties for the essentially same relation depending on the data type).
In German, "title" is an elaborate synonym for "book" indicating that the
speaker is educated enough to be aware of the fact that there are many
copies... And for the title page(s). And of course for our(?) title in the
sense of denomination.
For the "data" world this means to me that BF has to be conceptually flexible
enough to map from/to the flattest descriptions imagineable (unqualified DC or
even less like scanned tables of contents) to data born in FRBR inspired
environments. So for some users "title" is and will ever be a "direct"
attribute of their resources, for others something transcribed from a
certain physical part of the resource (or they even make manifest the
bf:Instance or bf:Item involved), and others assign something as the result of
intellectual analysis of the content of the resource (archivists) or part of
So there /will/ be data not respecting the distinction between the classes
bf:Work, bf:Instance and bf:Item. And even more data not making use of
(instances of) the bf:Title class coined for modeling complex situations.
Looking at this hypothetical data one will not be able to "correct" that
(two "titles" given, could one be the spine title? or the original title
for the work? or a parallel title?), the information needed is simply
not there at all.
Having properties with quite specific domains will not prevent users from
"mis-using" that in the sense that they won't explicitly create all the
intermediate resources in their data to cohere to some concept of "strict
classing". But by domain considerations you can rather conclude that some
given resource in the data set has attributes turning it into a bf:Work
and bf:Title (and bf:Instance) at the same time: Depending on /your/
processing needs this might not matter at all or serve you as a warning
flag. In contrast to having distinctly named properties or giving most
properties the most general domains one cone think of I see some gain
in the approach.
<http://bibframe.example.com/workX> a bf:Work;
bf:workTitle [a bf:Title;
bf:titleValue “Lord of the Flies”].
is the more elaborate version of the "dumb" statement
<http://bibframe.example.com/workX> bf:title “Lord of the Flies”.
but what if the domain of bf:title would be defined as bf:Title
and therefore the existence of a bf:Title resource is implied
(and in this instance not distinguished from
<http://bibframe.example.com/workX>, whose bf:Work- or bf:Instance-ness might
not have been
established yet)? Furthermore, since there are not many properties
"connecting to" bf:Titles one (sometimes) could even deduce that
<http://bibframe.example.com/workX> is an instance of one of the
title-bearing BF resources...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----