On Mon, May 21, 2012 at 1:19 PM, J. McRee Elrod <[email protected]> wrote:
> The Wikipedia description of RDF and triples reminds me of > the presuppositions behind PRECIS, which did not work. Resources proved to > be too varied, English word meanings too ambiguous, with many resources > unique, for the concept to work. > > We would have work records (if separate WEM records are the > pattern) supporting the single expression and single manifestation of > that work. We would have triples relevant to a single manifestation, > and tables populated with data for a single manifestation's description. > > http://en.wikipedia.org/wiki/Resource_Description_Framework It is possible that the wikipedia may not be a good introduction. I may also have introduced some confusion. A triple is a simply an assertion that a predicate holds or does not hold between two things. This is the language of predicate logic, not English. RDF does not carry a strong semantics, but to the extent that the predicate and the subject of the predicate are both identifiers, and hence cannot be any kind of string, the effect of ambiguity in natural language is attenuated. A record (in the sense of a MARC record) can be considered as a related collection of assertions made at a single time by a single utterer. The semantic functions of the of record is this grouping, and it is strictly necessary for correctness to continue to express this contextual information. For a collection of such statements to be valid, the statements must be consistent with one another - however it is possible for two different collections of statement describing the same thing to be mutually inconsistent (for example, since if both collections use FAST style headings, but with different opinions as to what to consider "the" subject of the work is). Deeper semantics can be added by using more expressive ontology languages and more powerful reasoning systems. For example, many of the properties of an Item are the same for all the Items that are examples of the same Manifestation. There may be some abnormal items for which the property does not hold (e.g., a copy may be missing some pages, or may have a particular numbered copy of a limited edition). If we do not have any information to the contrary, we can infer that the title of a particular item is the same as the title of its manifestation. Similarly, if we don't have any information to the contrary, we can infer that the title of the manifestation is the same as the title of the expression it embodies, and the expression, the work it realizes. Note that this is similar to inheritance in object-oriented programming, but the relationships between the different FRBR entities is not genus/species; a Manifestation is not a kind of Expression. One should note that in the IFLA FRBR model there are some properties that are only applicable at certain levels; for example, language is a strictly a property of an expression. For properties like this, there is only one place where we can enter them. If one believes it to be a category error to ask what the language of an expression is, then one would not allow manifestations to inherit that property from expressions. So, for the case of the single manifestation of the single expression of a work, there is either only one level where we have to state a particular piece of information, or there is only one level where we are allowed to state it. Discussions of tables are only relevant in when talking about implementation in a particular RDBMS. Allen Renear and Yunseon Choi (Renear and Choi, 2006) presented a paper on inheritance in FRBR at the 2006 ASIS&T conference which is not *entirely*wrong. I believe that Allen accepts the inheritance of properties like title, and possibly the inheritance of most properties between manifestation and item. I'm Cc'ing Allen so he can can correct this. Simon [Renear, A. H. and Choi, Y. (2006). Modeling our understanding, understanding our models - the case of inheritance in FRBR. In Proceedings of the 69th ASIS&T Annual Meeting, vol. 43. http://eprints.rclis.org/handle/10760/8622#.T7ryCnlYsWg
