Hi Karen -


From: †Karen Coyle

> Ray, the document has a set of discussion points in the area of classes v.

> properties. It states that classes are more reusable, that the type is

> independently conveyed, that queries are more efficient, and that there is

> graceful degradation when properties are unknown.


> These "facts" are stated, but only for the last is there any

> discussion/explanation.


Well they're not exactly stated as facts but rather as arguments. †These arguments were all †advanced during the long discussion on properties vs. classes.


> I didn't understand your statement about re-usability:

> "When a BIBFRAME bf:Title resource is created it may be a linked data

> resource that can be reused outside of BIBFRAME."


It's simply the age-old argument about blank nodes versus† linked data resources.† Sorry if it's stated a bit obliquely.† And I grant that it's more important in some cases than others. †Personally, I am not as offended by blank nodes as many other people are. ††However, this point needs to be taken in combination with point 3 (next) to make sense, that is, if you publish it as a linked data resource, you should declare as specific a class as possible.



> My question about Type independently conveyed is similar. The document

> says: "Using the class to reflect the type means that the type will be known

> when it is used as such. If the type is conveyed only by the BIBFRAME

> property then that type will be known only when accessed in the BIBFRAME

> context."

> What I suspect you are referring to here is the explicit (rather than

> inferred) use of rdf:type to indicate the class of the subject - is that correct?


Not exactly.†† Consider:



†††††††† -xyz†††† hasAbbreviatedTitle†††† [


†††††††††††††††††††††††† a† bf: Title† ;

†††††††††††††††††††††††† rdfs:label† "abbr. title." . ] .††††





†††††††† -xyz†††† hasTitle†† [

†††††††††††††††††††††††† a† bf:AbbreviatedTitle†

†††††††††††††††††††††††††rdfs:label† "abbr. title." . ]† .††††


And let's say we create a linked data bf:Title resource in both cases.†† For (2) you'll know it's an AbbreviatedTitle. For (1) you won't.


The argument is stronger for identifiers:




†††††††† -xyz†††† bf:isbn††† [


†††††††††††††††††††††††† a† bf: Identifier† ;

†††††††††††††††††††††††† rdf:value†† "1234567890" . ] .††††





†††††††† -xyz†††† bf:identifiedBy†† [


†††††††††††††††††††††††† a† bf: Isbn† ;

†††††††††††††††††††††††† rdf:value†† "1234567890" . ] .†††† .††††


For (1) you donít have a clue that itís an Isbn, and so the value is useless.


(And we will have an identifier proposal out sometime hopefully soon that will propose this approach.)



> If so, then it seems that a BIBFRAME "best practice" would be that types

> must always declared in the code, rather than having them be inferred, and

> perhaps that should be stated here. I am aware that many developers

> eschew inferencing because of the processing overhead, and again, if that is

> the thrust of your argument then it would be helpful for that to be stated so

> that users of BIBFRAME can follow suit.


I believe the jury is still out on whether this should be a BIBFRAME Best Practice.



Thanks for the comments.†† --Ray