LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  November 2014

BIBFRAME November 2014

Subject:

Re: [Topic] Types

From:

"[log in to unmask]" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Tue, 4 Nov 2014 07:46:32 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (29 lines)

On Nov 3, 2014, at 8:25 PM, Karen Coyle <[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."
> The process of adding to the vocabulary has been long and arduous. When laser discs came on the scene, a proposal was entered to add a type for laser disc to MARC. By the time the proposal was passed and the code was included in library systems, laser discs had gone the way of Betamax. We need a real world solution that responds to rapid change. 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: in the Linked Data world, that is no more difficult than defining it using the same language as was used for the original types and then publishing the definition at an HTTP URL, as has been discussed on this list previously. In fact, it is vastly easier than the process of updating a standard under the control of some semi-central organization.

It is not true that an URI minted by Library X will not be understood by any other institution, if Library X takes the straightforward steps of using an HTTP URI, using a standard language to create the definition, and publishing its definition at the URI. This is just Linked Data. If, later,  I am examining some set of triples that uses that unfamiliar URI, my software can dereference it, examine the (machine-processable) definition, and act thereon.

It is not true that a special extension method is needed to create subclasses that do not prevent information sharing. Simple triples on webpages will do because anyone can create new classes in that way, and our freedom to share data is not going to be impinged by someone who publishes a badly-made new class. The effect of a new type will be limited to its area of use. I can publish all the bad types I like, but until you use them in your data or someone whose data you want to use uses them, they do not affect you. If you do decide to use my new types, LC has absolutely nothing to say about it.

> All of this is probably also true for string data to some extent, but it seems to require more coordination when types are URIs or classes.

Machine-opaque string data is a much greater threat to our ability to share information.

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

I'm not sure that this is a strong example. It seems to me mostly to point to the fact that Bibframe lacks a subtype of Resource that is a supertype for Work and Instance. That (missing) type might be the domain of bf:title and probably several other properties.

> I point this out because the suggestion that you can remove the main class from the name does not mean that the named property is now "classless". In the case of bf:Identifier as a class, that is fine because bf:Identifier isn't associated specifically with particular BF entities (which are defined as classes, but tha