Another caveat:
If bf:workTitle is sub-class bf:Title, then this is inferencially
consistent:
:X a bf:Work
bf:workTitle[ a bf:Title ;
bf:titleValue"Heart of Midlothian" ] .
:Y a bf:Instance
bf:workTitle[ a bf:Title ;
bf:titleValue"The heart of Midlothian" ] .
and bf:workTitle is never of class bf:Work (because class-ness only
"flows" from property to subject, not vice versa). So a SPARQL query of
"get me all the triples for class=bf:Work" will retrieve
:X a bf:Work
but never bf:workTitle, regardless of what graph it is found in. You
*will* however be able to query for all bf:Title(s).
?True? I think so. Maybe I'll run a test.
kc
On 11/4/14 5:01 PM, Robert Sanderson wrote:
>
>
> Hi Karen, Adam,
>
> On Tue, Nov 4, 2014 at 7:21 AM, Karen Coyle <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> On 11/4/14 4:46 AM, [log in to unmask] <mailto:[log in to unmask]>
> wrote:
>
> On Nov 3, 2014, at 8:25 PM, Karen Coyle <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> This is true, but it leaves us with the dilemma of how do
> we add new types. In the MARC world, this has been a real
> problem. When you cannot use a string, the new type has to
> be defined in the vocabulary before it can be used "in the
> wild."
>
> If types are URI's then a library can mint its own URI
> (which will not be understood by anyone else, and may not
> be correctly used by its own system). If types are
> subclasses, then we have the problem that BF is "owned" by
> LC, and to add new subclasses we need an extension method
> that doesn't break our ability to share.
>
> It is not true that adding a new type is difficult: (etc)
>
>
> It's not technically difficult. It is "habitually" difficult
> because of the way the library world has handled standards in the
> past. And it sure looks to me like we're headed along that same
> path with BIBFRAME and with RDA.
>
>
> Given that it's not technically difficult, we should determine how to
> steer the ship away from the known dangerous waters.
>
> In my opinion, that steering goes something like:
>
> Ensure that the work:
> * is well founded on standards
> * is able to be understood by someone who does not have a 20 year
> cataloguing tenure
> * is well documented
> * is able to be implemented
> * is in fact implemented, and in the same way by two independent systems
>
> We should make it easy to adopt the well understood and better
> methodology. But the first step is to work on the technical side ...
> which is what we're doing. History alone will show whether we're
> successful :)
>
> Note the suggestion in the document that: " Aternatively,
> bf:title could be retained and bf:workTitle and
> bf:instanceTitle eliminated. bf:title would be
> distinguishable as a Work title (formerly, uniform title)
> or Instance title (formerly title proper) because it would
> be a property of a bf:Work or bf:Instance respectively."
> Some of the "sub" title properties, e.g. bf:workTitle,
> either have a domain of bf:Work or bf:Instance. bf:title
> has the domain of Title. The statement above assumes that
> you would know whether you have a work title or an
> instance title because the bf:title would take on the
> "class" from the bf:Work or bf:Instance that it describes
> (predicates?). This is that complicated part of RDF where
> the domain of the property defines the class of the
> subject, not vice versa (as in XML, for example). A
> property is not a property of a class; a property's domain
> determines the "classness" of the subject.
>
>
> Surely the subject's class is determined by a statement with the
> predicate "rdf:type"?
> You can *infer* a class based on the range or domain of predicates,
> but that doesn't somehow trump an absolute assertion ... which all of
> the examples have, and should be mandatory in any reasonable
> implementation.
>
> It's actually easier to *not* do it this way, as you can generate
> unintended inferences. If you mistakenly attached instanceTitle to a
> Work, that's not an error, it just implies to a reasoner that the Work
> is also an Instance. Much easier to just consistently use bf:title
> that has no such inferences.
>
> [snip much]
>
> If BIBFRAME is not assuming that the work title and the instance
> title are key "definers" of the entity, then that is fine.
>
>
> BibFrame should not do this if it is, and therefore it is (or should
> be) fine. :)
>
> Rob
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600
