[log in to unmask]" type="cite">
I agree that the use of "constraint" in RDF and OWL documentation is misleading - but then that is why the expression of "what we mean" in RDF is so useful for data and applications in bibliographic information retrieval services which deal explicitly with the way humans label things :-)
I and other members of the FRBR Review Group have read that documentation, and we hope we have understood it correctly. As far as I know, we have never claimed that the declaration of property cardinality constraints, or indeed domains and ranges, is a data validation technique.
However, I think the declaration of the intentions of a model, schema, ontology, or whatever you want to call it, in RDF is highly desirable as a first step in developing applications for data that purport to follow the model. That was the context of my presentation in Lisbon . I recall that the dominant topic in the discussion that followed was the meaning of "constraint" and data validation rather than the questions I raised in the presentation, so they remain unanswered :-(
So I can say that it is the intention of the FRBR Review Group to express the model using OWL cardinality constraints. The automatic identification of "sameAs" instances of Works and Manifestations by reasoners will be useful, for example, in applications that bring together FRBR-conformant data from multiple local sources. It may well be useless or harmful to other applications; I think it is up to the application. I repeat, if there is anything wrong with this, please (anyone) let us know!
Is there a specific reason you say "[the "realizes" relationship between FRBRer:expression and FRBRer:work has owl:qualifiedCardinality "1"] does not conform, AFAIK, to the E-R analysis in FRBR"? I think it is fairly clear from the FRBR report containing the results of applying E-R techniques that "one and only one" is the intended cardinality between Expression and Work, and Item and Manifestation.
 The FRBR ontology (pptx with animation): http://www.gordondunsire.com/pubs/pres/FRBROWL.pptx
 The FRBR ontology (pdf with no animation): http://dcevents.dublincore.org/IntConf/dc-2013/paper/view/139/158
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 .
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. " 
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. " 
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 , 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 , ICV , Shape Expression , 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.
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]> 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  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).  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?
--Karen Coylem: 1-510-435-8234skype: kcoylenet
--Karen Coylem: 1-510-435-8234skype: kcoylenet
-- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet