I agree with you that mapping BF to "constrained" (typed) RDA will be
necessary and useful.
At the end of my message, I tried to make the point that this won't be
possible. I used classes but it is better to use properties instead. Once
you map rdam:reproductionOfManifestation to bf:reproduction and
rdai:reproductionOfItem to bf:reproduction, you can't go back the other way.
That is, bf:reproduction does not contain the information you need to choose
the correct RDA property in the BF -> RDA mapping. You no longer know
whether you came from reproductionOfManifestation or reproductionOfItem.
Joe
--------------------------------------------------
From: "Fallgren, Nancy (NIH/NLM) [E]" <[log in to unmask]>
Sent: Wednesday, January 07, 2015 8:08 AM
To: <[log in to unmask]>
Subject: Re: [BIBFRAME] Constrained vs unconstrained schemas
> Hi All,
>
> FWIW . . .
> We are working with the "constrained" version (with a nod to Karen's
> comments re use of the term 'constrained') of RDA/RDF and mapping that to
> a BIBFRAME core vocabulary precisely because we don't know what a
> cataloging input UI will look like post-MARC or how BF will be generated
> from that input. Since BF and RDA have different structures, our thinking
> is to use the "constrained" RDA/RDF so that the RDA data can be
> reconstructed easily and losslessly back into its WEMI entities structure
> from BF should that prove useful or necessary.
>
> -Nancy
>
> Nancy J. Fallgren
> Metadata Specialist Librarian
> Cataloging and Metadata Management Section
> Technical Services Division
> National Library of Medicine
>
> [log in to unmask]
>
> -----Original Message-----
> From: Gordon Dunsire [mailto:[log in to unmask]]
> Sent: Tuesday, January 06, 2015 7:42 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Constrained vs unconstrained schemas
>
> All
>
> Many applications based on RDF data will need to know what type of thing
> is being described by a triple. An application can get that information
> implicitly, from the domain and range of the triple's property, or
> explicitly, from a separate triple stating the thing's type. There is no
> guarantee that such a type triple exists, or is connected to the local
> graph, or can be retrieved from the global graph.
>
> The quality (effectiveness, efficiency, etc.) of these applications is
> likely to depend on the accuracy and completeness of entity typing. More
> sophisticated applications are likely to depend also on the semantic
> coherence of the results of typing.
>
> Publishers of data based on specific ontologies should be able to choose
> whether to provide type triples implicitly or explicitly. Using properties
> constrained by domain and range allows implicit typing by applications
> intended to consume the data. The maintainers of the specific ontology are
> probably the best agents to provide data publishers and consumers with the
> RDF element sets for the constrained properties and, indeed, the type
> classes used to constrain them.
>
> Publishing data using constrained properties does not prevent its use by
> applications that are simple, low-quality, or do not require entity
> typing.
> Such applications may use RDF maps to dumb-down constrained properties to
> unconstrained versions, or simply ignore domains and ranges. The RDF maps
> may be local to the application, or provided by the maintainers of the
> constrained elements or some other agent.
>
> I agree that the publishers of library data in RDF should be able to
> specify how it is intended to be used by libraries: this is a closed-world
> assumption. The BF model seems to be mainly influenced by the data
> currently used by library applications based on MARC21; the FRBR model
> reflects the functional requirements to support world-wide consensus on
> user tasks. I think both of these bases, data and users, are good
> indicators of the needs of future library applications. I therefore think
> it is a benefit that the BIBFRAME Initiative (BFI), IFLA, and the JSC for
> RDA are providing constrained RDF element sets for BF, FRBR, ISBD, and
> RDA. I also think the provision of unconstrained element sets is a good
> thing, together with mappings from constrained to unconstrained
> properties. I do not know whether BFI intends to publish unconstrained
> properties. I do know that the FRBR Review Group decided not to do so
> because of its plans to consolidate the FRBR, FRAD, and FRSAD models (now
> approaching completion), and that the ISBD Review Group has an
> unconstrained element set ready for publication in the near future with a
> corresponding map.
>
> The JSC and ISBD Review Group have collaborated on a map between the ISBD
> and RDA elements [1]. The map, based on an updated version of the agreed
> element alignment [2] will be published in the next few weeks. It
> necessarily uses unconstrained properties to link well-formed ISBD and RDA
> data together, and was a stimulus to the development of the unconstrained
> ISBD element set. As noted in the pre-print cited by Karen, there is also
> a map between ISBD and FRBR classes which requires local semantics for
> "aspect" relationships [3].
>
> I am not convinced that the assumption that RDA Work and RDA Expression
> are equivalent to/same as BF Work is a useful or valid one [4]. I think
> there may be similar problems with RDA Manifestation, RDA Item, and BF
> Instance.
> The ISBD/RDA experience shows that careful consideration of implicit
> semantics in definitions and scope notes is required, as well as explicit
> semantics in domain, range, and sub-property relationships.
>
> So I do not advise mapping either the constrained or unconstrained RDA
> properties to constrained BF properties without further clarification of
> the class relationships. It is ok to map constrained BF properties to
> unconstrained RDA properties. A full map between RDA and BF requires the
> use of unconstrained RDA and BF properties. And, by definition, a
> roundtrip from constrained to unconstrained to constrained is somewhat
> lossy (as well as incoherent).
>
> I think we need further investigation of the relationship between the
> RDA/FRBR models and BF, probably best carried out by the JSC and BFI. And
> we need to test interoperability using orthodox RDA and BF data.
> Fortunately, we now have the beta of version 3 of RIMMF to create orthodox
> RDA data [5].
> So perhaps we can do something useful with RDA and BF data after the
> Jane-athon [6].
>
> Cheers
>
> Gordon
>
> [1] http://www.rda-jsc.org/docs/6JSC-Chair-4.pdf
> [2]
> http://www.ifla.org/files/assets/cataloguing/isbd/OtherDocumentation/ISBD2RD
> A%20Alignment%20v1_1.pdf
> [3]
> http://www.ifla.org/files/assets/cataloguing/isbd/OtherDocumentation/resourc
> e-wemi.pdf
> [4] http://www.gordondunsire.com/pubs/pres/RDAMARCBIBFRAME.pptx
> [5] http://www.rdaregistry.info/rimmf/index.html
> [6] http://www.rdatoolkit.org/janeathon
>
> If it is a camel, a weasel, and a whale, then it is a cloud (inferred from
> Hamlet, Act 3, Scene 2).
>
>
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
> Sent: 05 January 2015 23:21
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Constrained vs unconstrained schemas
>
> Thanks, this helps a lot. I had viewed domains as more restrictive than
> they are.
>
> I agree with your larger question that we need to understand the
> operations that will be performed on our data in RDF. Perhaps we can't
> anticipate what other people will do, but we should be able to specify
> what libraries will do.
>
>
> Joe
>
> --------------------------------------------------
> From: "Karen Coyle" <[log in to unmask]>
> Sent: Monday, January 05, 2015 1:38 PM
> To: <[log in to unmask]>
> Subject: Re: [BIBFRAME] Constrained vs unconstrained schemas
>
>> Joseph, You might want to look at my blog post on RDF classes:
>>
>> http://kcoyle.blogspot.com/2014/11/classes-in-rdf.html
>>
>> and the article by Baker-Coyle-Petiya
>>
>> http://kcoyle.net/LHTv32n4preprint.pdf
>>
>> There are actually no "constraints" in RDF, just potential inferences.
>> The inferences are based on the stated domains and ranges of the
> properties.
>> There are examples of this in the Baker et al article using RDA,
>> FRBRer and BIBFRAME. There is no conflict with a subject being
>> inferred as being an instance of more than one class as long as the
>> classes themselves are not declared as disjoint. (The article explains
>> this better than I can in an email. ) The documentation for RDA,
>> BIBFRAME and FRBRer all presents classes as determinants of data
>> structure. This, to me, is a common error in RDF development. That any
>> subject can be an instance of more than one class is necessary for the
>> RDF graph's flexibility, and should be proof that classes do not
> constraint your data to a single graph structure.
>>
>> The declared domains of properties only come into play if inferencing
>> is applied. A big question, therefore, is whether any inferencing will
>> be done at all over the data. The utility of, for example, the RDA
>> classes to me is that it allows you to do simple queries for
>> categories of triples, e.g. "give me all of the work triples for the
>> manifestation with this ISBN." Other than that you can ignore the fact
>> that domains have been declared if they don't serve your needs.
>>
>> Your question, however, brings up a much larger question that I
>> haven't seen discussed anywhere, which is: what kinds of operations do
>> we expect to perform over library data in RDF? That question really
>> should be answered before domains and ranges are defined, because that
>> is the function of those capabilities of RDF.
>>
>> kc
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 1/5/15 12:52 PM, Joseph Kiegel wrote:
>>> A comparison of BIBFRAME and RDA in RDF (referred to below as RDA),
>>> in an attempt to map RDA to BIBFRAME, raised the issue of constrained
>>> vs unconstrained schemas.
>>>
>>> The full set of RDA properties is constrained by the RDA classes of
>>> Agent, Work, Expression, Manifestation and Item. That is, each
>>> property is related to a specific class when appropriate: e.g.
>>> abridgementOfExpression and abridgementOfWork. A parallel set of
>>> properties has been created where the constraints of class are lifted:
>>> e.g. abridgementOf. This unconstrained version of RDA loses the
>>> context of some properties but is intended to facilitate mapping to
>>> schemas that do not use the FRBR model underlying RDA.
>>>
>>> BIBFRAME is a constrained schema, but constrained by different classes:
>>> Agent, Work, and Instance. There is no unconstrained version of
>>> BIBFRAME.
>>>
>>> A mapping of RDA to BIBFRAME presents choices and challenges.
>>>
>>> Is it better to use constrained RDA, which causes explicit conflicts
>>> of
>>> domain: e.g. mapping rdam:reproductionOfManifestation to
>>> bf:reproduction and rdai:reproductionOfItem to bf:reproduction?
>>>
>>> Or is it better to use unconstrained RDA, which still has conflicts
>>> (an unconstrained domain vs a constrained one in BIBFRAME): e.g.
>>> mapping rdau:reproductionOf to bf:reproduction?
>>>
>>> It is not obvious which is the better choice. Although perhaps we
>>> need both mappings, each with its own problems regarding original and
>>> destination domains.
>>>
>>> A corollary of the question is that any roundtrip RDA -> BF -> RDA is
>>> lossy. If constrained RDA is used as a starting point, RDA classes
>>> are lost in the mapping itself, and if unconstrained RDA is used,
>>> classes are lost prior to mapping. Either way, RDA classes cannot be
>>> recovered in a BF -> constrained RDA mapping.
>>>
>>
>> --
>> Karen Coyle
>> [log in to unmask] http://kcoyle.net
>> m: +1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>>
>
|