Another caveat:

If bf:workTitle is sub-class bf:Title, then this is inferencially 

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


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]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600