> This is what Karen's triples is effectively describing, however I feel
> a class of 'PublicationEvent', probably an extension of a base Event
> class, would be both a more flexible and more descriptive solution.
-- We've actually been leaning in just this direction. So as not to lose the synergy of the moment, take a look at
http://bibframe.org/tools/tests/test19.html
which represents a test case that models provider information as an event.
Now, the link goes to a new "tool" we've been working on that we believe will help us better capture these types of modeling considerations but it should be considered in "alpha." No promises links will function flawlessly or that information is displayed in the prettiest way, etc., but this seemed like a really good opportunity to introduce this new "tool" even if it is still a work-in-progress.
Yours,
Kevin
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Wallis,Richard
> Sent: Wednesday, June 26, 2013 4:06 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Changing BIBFRAME for more flexibility without
> losing library data meaning
>
> I would second Karen's warning to avoid the implicit capability of XML
> to nest things together. As she says RDF statements are valid in any
> order, and are not tied to XML.
>
> The particular use case here could be described as a publication
> associated with one or more publicationEvents. Each publicationEvent
> having a date, a location, and a publishing organisation.
>
> This is what Karen's triples is effectively describing, however I feel
> a class of 'PublicationEvent', probably an extension of a base Event
> class, would be both a more flexible and more descriptive solution.
>
> ~Richard.
>
>
> On 26/06/2013 12:17, "Karen Coyle" <[log in to unmask]> wrote:
>
> >Looking at the example:
> >
> >** example from below **
> ><bf:publication>
> > <bf:ProviderEntity>
> > <bf:providerName>Skira</bf:providerName>
> > <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> > </bf:ProviderEntity>
> > <bf:ProviderEntity>
> > <bf:providerName>Rizzoli</bf:providerName>
> > <bf:providerPlace>New York</bf:providerPlace>
> > </bf:ProviderEntity>
> > <bf:publicationDate>1983</bf:publicationDate>
> ></bf:publication>
> >
> >I think it is deceptive to to use XML in examples, even though you CAN
> >serialize RDF in XML. But XML is hierarchical in a way that RDF is not,
> >and one tends to fall into XML style rather than RDF style. We should
> >think about this in terms of:
> > subject - property - object
> >
> >If we turn the above into triples, we get:
> >
> >bookID - published - publicationID
> >publicationID - hasProvider - providerID providerID - providerName -
> >"name"
> >providerID - providerPlace - "name"
> >publicationID - hasProvider - providerID2
> >providerID2 - providerName - "name"
> >providerID2 - providerPlace - "name"
> >publicationID - publicationDate - "date"
> >
> >Note that these can be in any order, so the above is the same as:
> >
> >bookID - published - publicationID
> >providerID - providerName - "name"
> >providerID - providerPlace - "name"
> >providerID2 - providerName - "name"
> >providerID2 - providerPlace - "name"
> >publicationID - hasProvider - providerID publicationID - hasProvider -
> >providerID2 publicationID - publicationDate - "date"
> >
> >In all publication statements, the "provider" entity is nested under a
> >"publication" entity. Unfortunately, this structure would need to be
> >used for all publication statements, even those with only one
> >publisher/place -- which are the vast majority.
> >
> >** with single publisher **
> >bookID - published - publicationID
> >publicationID - hasProvider - providerID providerID - providerName -
> >"name"
> >providerID - providerPlace - "name"
> >publicationID - publicationDate - "date"
> >
> >This nesting will complicate any use of this data - this is especially
> >true if both publication and provider will be blank nodes, as I'm
> >guessing they will be. Another option is to create two publication
> >statements, rather than nesting the provider inside the publication
> >statement.
> >
> >** with single publisher **
> >bookID - published - publicationID
> >publicationID - providerName - "name"
> >publicationID - providerPlace - "name"
> >publicationID - publicationDate - "date"
> >
> >** with multiple publishers **
> >
> >bookID - published - publicationID
> >publicationID - providerName - "name"
> >publicationID - providerPlace - "name"
> >publicationID - publicationDate - "date"
> >bookID - published - publicationID2
> >publicationID2 - providerName - "name"
> >publicationID2 - providerPlace - "name"
> >publicationID2 - publicationDate - "date"
> >
> >I think this is a better solution in RDF.
> >
> >Also, note that the ordering mechanism used in the RDA vocabularies
> >does not actually have an RDF-based implementation -- today's RDF
> would
> >require the use of certain OWL mechanisms which are rarely used
> because
> >they are complex. RDF does not keep statements in order. If ordered
> >displays are absolutely necessary, it may make sense to have a textual
> >display that is separate from the data function of RDF. I'm actually
> >beginning to think that some aspects of library catalog data should be
> >treated as documents rather than data. Trying to force display
> >constraints into RDF doesn't seem like a good use of the technology.
> >
> >kc
> >
> >
> >On 6/25/13 12:01 PM, Thomas Dukleth wrote:
> >> [Original Subject: Re: [BIBFRAME] Scope misapplied with repeated
> >>subfields marc2bibframe bug #10]
> >>
> >> [Subject changed to appropriate topic for present message.]
> >>
> >> What can we do differently than what has been presented for using
> >>BIBFRAME or how can we change aspects of the BIBFRAME model to
> manage
> >>properties and data more flexibly for the linked data environment
> >>without losing meaning when converting our legacy records?
> >>
> >> I ask the question with the context of particular examples which
> seem
> >>to pose complications. Below I used one trivial example which I
> >>raised when I noticed a bug concerning its treatment. There are a
> >>great many other examples which we could use which pose a challenge
> >>to us with BIBFRAME for meeting the goals of both flexibility for
> >>data sharing and serviceability for preserving meaning in the
> library
> >>systems context.
> >>
> >> In the context of my bug report about repeated subfields, Diane
> >> Hillman raised the issue, if I understood correctly, that we should
> >> avoid pre-aggregation. I take from her reminder that we should
> >> distinguish between when aggregation is necessary for meaning and
> >> when it is not to avoid unnecessary pre-aggregation.
> >>
> >> Karen Coyle has argued in this thread and others that we should not
> >>be imposing our own legacy exclusively library centric model onto
> the data.
> >> She has emphasised the need to document what semantics are encoded
> in
> >>our legacy records to help us understand what is encoded in our
> >>legacy data in actual practise beyond merely MARC standards and
> >>cataloguing rules.
> >>
> >> What can we do specifically which will work for each particular
> >> problematic case we can find?
> >>
> >> It is difficult to make progress in a manner which will actually
> >>function properly in the real world without studying the most
> >>difficult cases of data representation one can find. While I have
> >>not taken the liberty, library science literature often uses
> >>artificial examples when discovering some actual examples of a
> >>particular problems may be difficult when needed for study. Some
> >>types of libraries are mainly concerned with records which I would
> >>consider difficult. Other examples may be infrequent in occurrence
> >>but numerous in their aggregate in all our collective records.
> >>
> >>
> >> 1. BASE EXAMPLE.
> >>
> >> This example may not be a very interesting example but perhaps it is
> >>worth considering as a problem for what to do to avoid unnecessary
> >>pre-aggregation. All code examples below are obviously mere extracts.
> >>
> >> People seem to have generally understood that an example which I had
> >>used previously was the problem of maintaining the correct
> >>relationship between some subfields within a field. In the case of
> >>the example which I presented, multiple publishers for the same
> >>manifestation need correct association of the particular publisher
> >>with the correct corresponding place of publication and publication
> >>date. This example happens to use a source field populated with
> >>transcribed data but the problem is independent of whether or not
> the
> >>data is transcribed.
> >>
> >> This not a mere academic exercise or limited to matching
> manifestations.
> >> Place in association with a publisher can constitute a distinct
> >>business with whom an order for the publication can be correctly
> >>placed for a copy of where as the same general publishing house name
> >>in a different place may know nothing of the publication.
> >>
> >>
> >> 1.1. SUGGESTED BIBFRAME EXAMPLE.
> >>
> >> The example has vocabulary from the currently listed BIBFRAME
> >> vocabulary in addition to my suggested bf:publicationDate property.
> >> The problem of preserving meaning remains the same irrespective of
> the vocabulary used.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:publication>
> >> <bf:ProviderEntity>
> >> <bf:providerName>Skira</bf:providerName>
> >> <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> >> </bf:ProviderEntity>
> >> <bf:ProviderEntity>
> >> <bf:providerName>Rizzoli</bf:providerName>
> >> <bf:providerPlace>New York</bf:providerPlace>
> >> </bf:ProviderEntity>
> >> <bf:publicationDate>1983</bf:publicationDate>
> >> </bf:publication>
> >> </bf:Instance>
> >>
> >>
> >> 1.2. SEQUENTIAL LIST.
> >>
> >> 1.2.1. RDA VOCABULARIES EXAMPLE.
> >>
> >> RDA vocabularies address the problem of preserving meaning by using
> >>an explicitly ordered sequential list in a rdvocab:
> >> PublicationStatementEncodingScheme,
> >> http://metadataregistry.org/schemaprop/show/id/764.html . The
> >>interpretation of association follows the sequence just as it does in
> >>MARC 21. Please correct my misuse of the RDA vocabulary if my usage
> >>is mistaken.
> >>
> >> <rdvocab:Manifestation>
> >> <!-- some other stuff -->
> >> <rdvocab:PublicationStatementEncodingScheme>
> >> <rdvocab:placeOfProductionManifestation>Geneva, Switzerland
> >></rdvocab:placeOfProductionManifestation>
> >> <rdvocab:publisherManifestation>Skira
> >></rdvocab:publisherManifestation>
> >> <rdvocab:placeOfProductionManifestation>New York
> >></rdvocab:placeOfProductionManifestation>
> >> <rdvocab:publisherManifestation>Rizzoli
> >></rdvocab:publisherManifestation>
> >> <rdvocab:dateOfPublicationManifestation>1983
> >> </rdvocab:dateOfPublicationManifestation>
> >> </rdvocab:PublicationStatementEncodingScheme>
> >> </rdvocab:Manifestation>
> >>
> >> Without nested or otherwise more explicit grouping, the intended
> >>implicit association between publisher and place of publication as
> >>well as date seems problematic. What is the reason for the use of
> >>problematic implicit association instead of more reliable explicit
> >>association?
> >>Does
> >> implicit use come from a problem of the excessive reliance upon
> >>language strings in the conventional cataloguing rules or the
> >>implementation in the RDA vocabulary, or both?
> >>
> >>
> >> 1.2.2. ONIX EXAMPLE.
> >>
> >> ONIX records would generally be issued by an individual publisher
> and
> >>not be very liable to have the complication of multiple publishers
> >>specified by any one publisher issuing ONIX records. XML is used
> for
> >>ONIX, not sets of RDF statements which may be expressed in XML,
> >>however, there should be value in studying especially how allied
> >>communities exchange metadata.
> >>
> >> In the ONIX schema, the PublishingDetail element is not repeatable
> >>and no element has been created to act as a repeatable parent
> element
> >>to associate elements for a particular publisher, such as publisher
> >>and place of publication elements. Pretending that specifying an
> >>ordered sequence of elements provides an implicit association by the
> >>grouping in ONIX XML similar to RDA Vocabulary RDF may be an
> approach
> >>to take for recording such associations in ONIX.
> >>
> >> The dissatisfaction of the less reliable implicit over the more
> >> reliable explicit would be the same problem as with the use of the
> >> PublicationStatementEncodingScheme in the RDA vocabulary.
> >>
> >> ONIX functions more appropriately where a need has been anticipated
> >>in the context for which ONIX has been created as a means of
> >>communicating product information in the book trade. ONIX has also
> >>not had the long history and wide application of MARC to give rise
> to
> >>managing especially diverse use cases.
> >>
> >> <Product>
> >> <!-- some other stuff -->
> >> <PublishingDetail>
> >> <Publisher>
> >> <PublisherName>Skira</PublisherName>
> >> </Publisher>
> >> <CityOfPublication>Geneva, Switzerland</CityOfPublication>
> >> <Publisher>
> >> <PublisherName>Rizzoli</PublisherName>
> >> </Publisher>
> >> <CityOfPublication>New York</CityOfPublication>
> >> <PublishingDate>
> >> <PublishingDateRole>01</PublishingDateRole>
> >> <Date dateformat="05">1983</Date>
> >> </PublishingDate>
> >> </PublishingDetail>
> >> </Product>
> >>
> >>
> >> 2. FLATNESS OF HIERARCHY.
> >>
> >> Perhaps flatness of the hierarchy is an issue for flexibility of use.
> >>
> >> All the properties of bf:publication property could be properties of
> >>the bf:Instance directly without needing to have the bf:publication
> >>property.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:ProviderEntity>
> >> <bf:providerName>Skira</bf:providerName>
> >> <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> >> </bf:ProviderEntity>
> >> <bf:ProviderEntity>
> >> <bf:providerName>Rizzoli</bf:providerName>
> >> <bf:providerPlace>New York</bf:providerPlace>
> >> </bf:ProviderEntity>
> >> <bf:publicationDate>1983</bf:publicationDate>
> >> </bf:Instance>
> >>
> >>
> >> 3. DIFFERENT ASSOCIATIONS.
> >>
> >> Some possible case might have different publication dates for
> >> different publishers reported for the same bf:Instance entailing
> >> appropriate date associations.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:ProviderEntity>
> >> <bf:providerName>Skira</bf:providerName>
> >> <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> >> <bf:providerDate>1982</bf:publicationDate>
> >> </bf:ProviderEntity>
> >> <bf:ProviderEntity>
> >> <bf:providerName>Rizzoli</bf:providerName>
> >> <bf:providerPlace>New York</bf:providerPlace>
> >> <bf:providerDate>1983</bf:publicationDate>
> >> </bf:ProviderEntity>
> >> </bf:Instance>
> >>
> >>
> >> 4. POSSIBLE SEQUENCE INDEPENDENCE.
> >>
> >> The sequence of the data might not matter for the meaning as in the
> >>following reordering of the sqeuence. However, the sequence of data
> >>might matter for distinguishing instances in which the sequence of
> >>data in the material is a signifier of a difference in the instance
> >>and thus might need to be preserved in some application profile
> which
> >>serves a community needing the sequence to be maintained.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:ProviderEntity>
> >> <bf:providerName>Rizzoli</bf:providerName>
> >> <bf:providerPlace>New York</bf:providerPlace>
> >> </bf:ProviderEntity>
> >> <bf:publicationDate>1983</bf:publicationDate>
> >> <bf:ProviderEntity>
> >> <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> >> <bf:providerName>Skira</bf:providerName>
> >> </bf:ProviderEntity>
> >> </bf:Instance>
> >>
> >>
> >> 5. ADDITIONAL HIERARCHY FLATNESS.
> >>
> >> Supposing that some people would consider flatness of hierarchies to
> >>be an issue for flexibility of use, how far can flatness go without
> >>losing meaning?
> >>
> >> How could the hierarchy be flattened any further to make
> >>bf:providerEntity properties, such as bf:providerName, properties of
> >>the bf:Instance directly without losing the meaning of the
> >>relationship between a particular publisher and a particular place
> of
> >>publication in the same instance?
> >>
> >> Kevin Ford reported that there has been discussion of flattening the
> >> provider hierarchy entirely.
> >>
> >> Is the marc2bibframe conversion for this case from six months ago
> >> something like what would be expected from flattening the provider
> >> hierarchy?
> >>
> >> The property vocabulary in use from six months ago seem more general
> >> purpose and flexible, such as the use of bf:label in various
> >> contexts, than the more library specific vocabulary which has been
> >> published subsequently. The more general vocabulary seemed to
> >> require use in some small hierarchy to convey appropriate meaning to
> the data.
> >>
> >> Six months ago marc2bibframe conversion also produced something like
> >>the following with no association between particular publishers and
> >>particular places, but has improved greatly with some but perhaps
> too
> >>much pre-aggregation in the interval. The relationship between a
> >>particular bf:providerName and bf:providerPlace would have been lost
> >>and consequently many functions of the publication information would
> >>not work. As stated further above, international publishers often
> >>have entirely different businesses in different places, so that
> >>seeking information or purchasing copies of a publication requires
> >>seeking the correct publisher in the correct place.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:provider>
> >> <bf:Organization>
> >> <bf:label>Skira</bf:label>
> >> </bf:Organization>
> >> </bf:provider>
> >> <bf:provider>
> >> <bf:Organization>
> >> <bf:label>Rizzoli</bf:label>
> >> </bf:Organization>
> >> </bf:provider>
> >> <bf:placePub>
> >> <bf:Place>
> >> <bf:label>Geneva, Switzerland</bf:label>
> >> </bf:Place>
> >> </bf:placePub>
> >> <bf:placePub>
> >> <bf:Place>
> >> <bf:label>New York</bf:label>
> >> </bf:Place>
> >> </bf:placePub>
> >> <bf:pubDate>1983</bf:pubDate>
> >> </bf:Instance>
> >>
> >> A comparably flat version with currently published experimental
> >> BIBFRAME vocabulary would be as follows.
> >>
> >> <bf:Instance>
> >> <!-- some other stuff -->
> >> <bf:providerName>Skira</bf:providerName>
> >> <bf:providerName>Rizzoli</bf:providerName>
> >> <bf:providerPlace>Geneva, Switzerland</bf:providerPlace>
> >> <bf:providerPlace>New York</bf:providerPlace>
> >> <bf:providerDate>1983</bf:publicationDate>
> >> </bf:Instance>
> >>
> >> Would it be acceptable to only have meaningful associations in a
> >> special library centric application profile and leave the rest of
> the
> >> world mystified about the functionality of our data when it is
> >> sufficiently complex to be ambiguous without associations?
> >>
> >>
> >> 6. DIANE HILLMANN.
> >>
> >> [Reply continues inline.]
> >>
> >>
> >> On Mon, June 17, 2013 19:10, Diane Hillmann wrote:
> >>> I've been watching this particular conversation and am concerned
> >>>that the focus on the technical questions carves the old
> assumptions
> >>>about 'statements' of all kinds into stone, again.
> >>>
> >>> Publication statements began as a sensible shorthand based on the
> >>>model of a 3 x 5 card with a hole in the bottom. Since then we've
> >>>fallen back on that once useful shorthand and not sufficiently
> >>>questioned the association that they belong together in a
> >>>description, particularly one not based on that old model. Yes, we
> >>>have data in that form everywhere, and the current rules continue
> to
> >>>rely on transcription, which makes it difficult to move beyond
> >>>traditional practices.
> >>>
> >>> But this strategy, which we might call 'pre-aggregation'
> >>>unnecessarily limits how we might take advantage of a much
> broadened
> >>>approach to data use and sharing. In the RDA Vocabularies, we made
> >>>an initial stab at separating the elements so that they could be
> >>>described separately (with some hope of taking advantage of other
> >>>community's work on geographics and publisher names), but also
> >>>including a way to aggregate them into a statement, with each piece
> >>>in order.
> >>> Granted, there are some parts of that strategy still TBD, but this
> >>>strategy more fully separates issues of description from those of
> >>>display.
> >>>
> >> 7.1. EXTENT
> >>
> >>> There is at present a CC:DA group attempting to apply similar
> >>>thinking to another place where traditionally a number of disparate
> >>>pieces of information lose much of their utility because they have
> >>>been
> >>> 'pre-aggregated': the extent of the resource. The report of that
> >>>Task Force is available at:
> >>>
> >>>http://alcts.ala.org/ccdablog/wp-
> content/uploads/2012/06/tf_MRdata4.p
> >>>df
> >>> and
> >>> will be discussed at the Saturday meeting of CC:DA at the ALA
> Annual
> >>>meeting in less than two weeks.
> >> Extent with all the human readable language specific strings is one
> >>of the least machine readable aspects of treatment in MARC 21. I
> >>presume that the current published treatment of extent in BIBFRAME
> is
> >>merely awaiting due consideration to parse into appropriately typed
> >>units and avoid the excessive use of language strings.
> >>
> >>> Diane
> >>>
> >>
> >> 8. KAREN COYLE.
> >>
> >> [Further comment at the end of the message quoted from Karen Coyle.]
> >>
> >> On Tue, June 18, 2013 19:06, Karen Coyle wrote:
> >>> I actually like the "combining things in various ways" of
> aggregation.
> >>> Rather than having fixed "sets" or "systems" I think we need for
> our
> >>> data to be able to represent a number of different, and perhaps
> even
> >>> conflicting, views. I know that the library cataloging function has
> >>> a need for a fixed set of elements and relationships so that
> sharing
> >>> is efficient, but I don't think that our data will interact widely
> >>> on the web in such a rigid format. I would like concepts like Work
> >>> and Instance, or WEMI, to have clarifying meaning, but not to
> >>> restrict the usage of the properties for the range of information
> >>> sharing activities that the open Web can provide.
> >>>
> >>> This reflects some questions that I have about BIBFRAME -- is it
> >>> developing a cataloging record? open web linked data? a local
> >>> systems record? I'm not clear on the scope and goals. The initial
> >>> BIBFRAME document (which unfortunately is given a file name
> >>> beginning with "marcld" -- MARC as linked data?) says:
> >>>
> >>> "It is designed to integrate with and engage in the wider
> >>> information community while also serving the very specific needs of
> >>> its maintenance community..."
> >>>
> >>> I think you can do this, but it won't be done as a single model of
> >>> entities. You need a model that can *sometimes* have bf:Works and
> >>> bf:Instances and *sometimes* have frbr:WEMI, and *sometimes* be
> >>> presented as an MLA citation. The only valid "set", IMO, is the set
> >>> of elements that give you what you want in a certain context. One
> of
> >>> those contexts is library cataloging.
> >>>
> >>
> >> 8.1. APPLICATION PROFILES.
> >>
> >>> This is where I think application profiles come in. You can define
> >>> elements that are not tied to a particular system, then define any
> >>> number of application profiles using those elements. One AP would
> be
> >>> BIBFRAME. Another might be FRBR. yet another ISBD. Another might be
> >>> an MLA citation. All using the same elements, and thus easily
> >>> interoperable. You constrain at the application level, not at the
> >>> element level.
> >>>
> >>> More on APs and the discussion we will have in the fall:
> >>>
> >>> http://dcevents.dublincore.org/IntConf/index/pages/view/APaltOO
> >>>
> >>> And I'm working on an analysis of Open Annotation and BF
> annotations
> >>> using application profile concepts.
> >>>
> >>> kc
> >>>
> >> We need to study concretely how particular working models for
> >>application profiles will function in the context of BIBFRAME as
> well
> >>as concretely how actual data sharing will happen with a wider
> >>community before any aspect of BIBFRAME becomes a fait accompli.
> >>Mere undemonstrated belief that whatever will be in BIBFRAME
> together
> >>with some future application profile development will serve all
> needs
> >>sufficiently will not be enough to ensure that BIBFRAME will
> actually
> >>achieve its objectives.
> >>
> >>
> >> 9. BIBFRAME DEVELOPMENT MODEL.
> >>
> >> In the agile software development model supposedly being pursued for
> >>BIBFRAME, there must be a willingness to discard mistaken approaches
> >>even at a late stage to avoid a bad outcome. Discarding mistakes
> >>should be the price which is paid for agile development relative to
> >>slower more careful development models which attempt to model more
> >>completely at each stage at the price of the speed at which
> >>functioning code can be seen. Such flexibility in development
> should
> >>merely be another aspect of the flexibility which we need BIBFRAME
> to
> >>fulfil for our data.
> >>
> >>
> >> Thomas Dukleth
> >> Agogme
> >> 109 E 9th Street, 3D
> >> New York, NY 10003
> >> USA
> >> http://www.agogme.com
> >> +1 212-674-3783
> >
> >--
> >Karen Coyle
> >[log in to unmask] http://kcoyle.net
> >ph: 1-510-540-7596
> >m: 1-510-435-8234
> >skype: kcoylenet
> >
|
