Print

Print



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:



(1)

         -xyz     hasAbbreviatedTitle     [



                         a  bf: Title  ;

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



Versus



(2)

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





(1)

         -xyz     bf:isbn    [



                         a  bf: Identifier  ;

                         rdf:value   "1234567890" . ] .



Versus



(2)

         -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