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.


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]
> [2]
> A%20Alignment%20v1_1.pdf
> [3]
> e-wemi.pdf
> [4]
> [5]
> [6]
> 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:
>> and the article by Baker-Coyle-Petiya
>> 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
>>> 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]
>> m: +1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600