On 7/26/14, 2:27 AM, Gordon Dunsire wrote:
> This is what FRBR actually says: “The methodology used in this study 
> is based on an entity analysis technique that is used in the 
> development of conceptual models for relational database systems. 
> Although the study is not intended to serve directly as a basis for 
> the design of bibliographic databases, the technique was chosen as the 
> basis for the methodology because it provides a structured approach to 
> the analysis of data requirements that facilitates the processes of 
> definition and delineation that were set out in the terms of reference 
> for the study.”
> I don’t think that’s quite the same thing. In any case, a normalized 
> RDBMS is a very good fit indeed with the RDF world; see, for example, 
> the work of the W3C RDB2RDF Working Group [1].

This is all very complex, and I hardly feel that it can be adequately 
covered in an email exchange, nor that I can give the absolute, 
definitive answer. It also may be too orthogonal to the concerns of most 
people on this list. However, I will try, and welcome others to weigh in.

tl;dr: 1) E-R and RDF have some similarities, but are not semantically 
the same, especially in how they define "class" 2) OWL is not a 
constraint language for instance data, but a language for testing axioms

First, I'd disagree with "very good fit." In fact, that documentation says:

" Is the RDF model an entity-relationship mode? Yes and no. It is great 
as a basis for ER-modelling, but because RDF is used for other things as 
well, RDF is more general. RDF is a model of entities (nodes) and 
relationships. If you are used to the "ER" modelling system for data, 
then the RDF model is basically an openning of the ER model to work on 
the Web. In typical ER model involved entity types, and for each entity 
type there are a set of relationships (slots in the typical ER diagram). 
The RDF model is the same, except that relationships are first class 
objects: they are identified by a URI, and so anyone can make one. 
Furthurmore, the set of slots of an object is not defined when the class 
of an object is defined. The Web works though anyone being (technically) 
allowed to say anything about anything. This means that a relationship 
between two objects may be stored apart from any other information about 
the two objects. This is different from object-oriented systems often 
used to implement ER models, which generally assume that information 
about an object is stored in an object: the definition of the class of 
an object defines the storage implied for its properties. " [1]

The exceptions noted here are significant. Yes, you can transform an 
RDBMS or an E-R model to RDF for the convenience of working within the 
RDF world. But note that both RDF and OWL documentation caution against 
transferring E-R or OO *concepts* to RDF. To me, the key point is this: 
"Furthurmore,[sic] the set of slots of an object is not defined when the 
class of an object is defined." The role of classes in RDF is very 
different from the role of classes in E-R and OO. That you CAN transform 
an RDBMS to RDF does not mean that the same semantics apply. Caution 
should be applied, and some adjustments may need to be made.

> Karen also said “FRBR has an OWL vocabulary called ‘FRBRer’ that has a 
> whole host of problems (not the least of which is a fairly deep 
> misunderstanding of OWL).” I am sure the FRBR Review Group would like 
> to correct any problems, so it would be useful if you could elaborate 
> on what the problems are. Also, please let us know what is being 
> misunderstood about OWL.

Gordon, I assumed we had covered this at the DCMI2013 meeting in Lisbon 
during the session on application profiles, where it was made explicit 
that OWL is not a data validation language, which is why there is an 
interest in application profiles that DO provide constraints. The 
concept of "constraints" in OWL is not at all analogous to the concept 
of constraints in languages like XSD, or in E-R modeling. In fact, as 
the OWL documentation says:

" OWL 2 is not a schema language for syntax conformance. Unlike XML, OWL 
2 does not provide elaborate means to prescribe how a document should be 
structured syntactically. In particular, there is no way to enforce that 
a certain piece of information (like the social security number of a 
person) has to be syntactically present. " [2]

In other words, 1) classes are not structures in RDF, although they 
often perform a structural role in E-R and OO; and 2) OWL axioms do not 
and cannot constrain the creation or validation of instance data: OWL 
can only infer "truths" from data that exists. (Yes -- see below -- ICV 
and others are using OWL with modified semantics to validate data. Note: 
"modified semantics.")

For the latter issue in that previous paragraph, the Open World 
Assumption means that if owl:qualifiedCardinality on SSN is "1", and no 
SSN is available, this is not an axiomatic inconsistency. In fact, 
reasoners do not even note this fact because it is axiomatically "true". 
(It's not terribly hard to test this in software like Protege.) It 
merely means that the application will assume that there is an SSN 
somewhere, just not here, now. If instead the search or reasoner finds 
two SSNs, SSN1 and SSN2, it will conclude that

SSN1 owl:sameAs SSN2

That is quite different from how an E-R diagram or an RDBMS interprets 
"one and only one." That is because OWL makes use of the non-unique name 
assumption - that the same thing can have more than one name (URI). Note 
that the same would be true in the use of owl:qualifiedCardinality in 
FRBRer [0], where the "realizes" relationship between FRBRer:expression 
and FRBRer:work has owl:qualifiedCardinality "1". Thus, if a 
FRBRer:expression is a FRBRer:realizationOf more than one FRBRer:work, 
those works will be understood, axiomatically, as being the same work. 
Therefore, if, in a particular environment (locally bounded or open on 
the web), one has these two statements where owl:qualifiedCardinality 
for FRBRer:realizationOf is "1"...

ResourceB FRBRer:realizationOf ResourceC
ResourceB FRBRer:realizationOf ResourceD

Regardless of the human-meaningful values of ResourceC and ResourceD, 
the inferred meaning is:

ResourceC owl:sameAs ResourceD

The identity of ResourceC could be intellectually "Moby Dick" and 
Resource D "Little Women." But OWL reasoners will not find an 
inconsistency between owl:qualifiedCardinality "1" and more than one 
available resource.

This is not what would result from and entity-relation statement of "one 
and only one," and it is quite different from how one might use 
cardinality in a *prescriptive* language, like XSD, or in OOP. It does 
not conform, AFAIK, to the E-R analysis in FRBR. Nothing about OWL 
constrains instance data to conform to what has been defined in OWL, and 
OWL reasoners do not return "error messages" for some situations that 
would trigger such messages in other languages. At the same time, some 
inconsistencies, such as properties that violate disjointness axioms, 
can result in the inability of the reasoner to operate at all on the 
data. (This depends on the actions programmed into the reasoner.)

OWL allows inferences on existing data, within the Open World Assumption 
and Non-Unique Name assumption. (I wish that OWL "constraints" had 
instead been named "axioms" because that is what they are.) It is for 
this reason that RDF validation languages, like SPIN [3], ICV [4], Shape 
Expression [5], and others are being investigated in W3C -- because 
nearly everyone has a need for validation, and OWL does not provide that.

How this all relates to FRBRer, RDA and BIBFRAME is quite complex, but 
hopefully there will be an article out on this topic before the end of 
the year. The upshot is that moving from E-R and OO into RDF requires 
some adjustments, both in thinking and modeling. It is also a good idea 
to create tests that challenge our "previous software model" assumptions.

[5] <>

> Cheers
> Gordon
> [1]
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle
> *Sent:* 26 July 2014 02:10
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] BF vocabulary and RDA
> On 7/25/14, 4:45 PM, Robert Sanderson wrote:
>     While we're piling on...
>     On Fri, Jul 25, 2014 at 4:38 PM, Philip Evan Schreur
>     <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>      Structure and data needs come first. Once that's settled, we look
>     to see how RDA can be expressed in that structure.
>     This is exactly it.  Bibframe should support RDA, not be
>     constrained by it.  Additional constraints can be layered on top,
>     for example via profiles.
> And RDA could be one of those profiles. But *something* has to be the 
> basis for the underlying data model. I believe that's what FRBR was 
> trying to be, but unfortunately, FRBR was designed around relational 
> database concepts and does not fit well into the RDF world. BIBFRAME 
> has devised its own model, although I'd like to see more discussion of 
> what that model is trying to represent. (Remember that many people are 
> not happy at how BF item data is modeled, and the definition of BF 
> annotation is still quite unclear.)
> RDA has its own RDF vocabulary [1] and may soon have a data creation 
> platform (at least a beta). (Note that RDA has 1676 properties (!).) 
> FRBR has an OWL vocabulary called "FRBRer" that has a whole host of 
> problems (not the least of which is a fairly deep misunderstanding of 
> OWL). [2] We have no dearth of RDF vocabularies (there's even one for 
> ISBD), but it's still not clear to me what direction we are going in 
> or what are the principles guiding the development of BIBFRAME. Not 
> that I would want to turn BIBFRAME development over to the catechism 
> that guides IFLA, but, really, what is it that we are doing?
> kc
> [1]
> [2]
> Rob
> -- 
> Karen Coyle
> [log in to unmask]  <mailto:[log in to unmask]>
> m: 1-510-435-8234
> skype: kcoylenet

Karen Coyle
[log in to unmask]
m: 1-510-435-8234
skype: kcoylenet