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