On 3/27/12 10:06 PM, Ben Companjen wrote: This is the beginning of the discussion about RWO's vs. bibliographic entities:
http://www.mail-archive.com/[email protected]/msg00076.html It's an ontological question - what is the entity that is being modeled? >> As for using the VIAF ID rather than the individual ID, I'm not entirely >> sure about that. As VIAF grows, individual library authority identifiers >> can move from one cluster to another. The VIAF id identifies the >> cluster, not the individual heading. >> The cluster itself does not have a string to match against. > > I'm not entirely sure what you mean - my understanding of VIAF is that > a VIAF ID identifies a person and that the underlying database > connects IDs from the individual authority files. I don't know whether > VIAF IDs are reused when one becomes obsolete (e.g. after a merge). We may need to ask, but my understanding is that the VIAF ID identifies a cluster of name authority statements that are considered to be for the same entity. However, if you look at VIAF you often see more than one cluster for the same entity. Presumably these will eventually be resolved. The resolution, as I understand it, will be to re-cluster the individual name authority entries. I do not know if the previous VIAF ID will be redirected to the new cluster. But I am pretty sure that the matching actions take place on the individual name authority records, not on the clusters. The primary issue that I see, however, is that there is no preferred form of the name for a cluster - the cluster keeps as preferred forms all of the preferred forms from all of the clustered name authority records. So at the point that you need to either compare a string to something in VIAF, or make use of VIAF, you must operate on the records in the cluster - there is no VIAF name data as such. As an ID, VIAF identifies a cluster of declarations about a named entity, and those declarations can have significant differences. >> Ideally, the name headings from US MARC records would be matched with >> the US name file, the name headings from (say) the National Library of >> Spain would be matched with that name file (all in VIAF), etc. > > Do you mean that by matching name headings to authority records > directly, we can circumvent VIAF but still get the identifiers used in > various (national) libraries? That should be possible, I guess. In VIAF you will be matching name headings to the VIAF capture of the authority records from the various libraries. >> Again, there are some folks who feel that the lack of expression is >> problematic, although OL is not the only database to skip that entity. I >> believe that the Edition is expression+edition, and that Work is pretty >> close to FRBR work. > > Let those people create their own dataset that connects works and > editions through Expressions that they control :D > Pseudo-triples: > <X Expression> <realizationOf> <OL Work>. > <OL Edition> <embodimentOf> <X Expression>. > > Perhaps in the future Open Library allows for creating this within its > own boundaries (/type/expression + links)? Or some fork of OL? > (N.B. I haven't met those people - I haven't really met any of you :) > - and don't intend to offend anyone.) It's not a matter of connections -- there are data elements that are designated as being Expression entity elements. This includes language, format, and some collaborators (translator, illustrator, etc.). This entity is meaningful (to those for whom it is). In OL, that information is in the Edition record, which means that in OL it is currently not possible to act on an Expression in the way that is intended in FRBR. I don't see this as a big problem, and it could be corrected, but I do think it is important to understand the intention of FRBR -- it is not an IT data structure but a conceptual model, and the concepts of the model are both clear and important to those who developed it. There is an Expression entity because it is considered to be conceptually important in describing bibliographic resources, and it is considered to be distinct from both the Work and the Manifestation (Edition). kc > > I don't think anything needs to be changed in respect of RDF FRBR > relations, by the way - I just remembered it being said. >> >> kc > > Ben >> >>> >>> I think these were the main topics related to RDF. The topics changed >>> to types and documentation of types, then to finding out what actually >>> _is_ in the data. >>> >>> Yesterday I changed the RDF templates (in my fork) to output correct >>> XML Schema dateTime values, because the Sindice Inspector [5] failed >>> reading the Open Library Work RDF [6]. >>> >>> I'd like to hear from others what (else) still needs to be changed >>> before the RDF templates can be updated (or what may be wrong in my >>> thinking). >>> >>> Regards, >>> >>> Ben >>> >>> [1] https://github.com/internetarchive/openlibrary/issues/145 >>> [2] https://github.com/internetarchive/openlibrary/pull/136 >>> [3] https://github.com/internetarchive/openlibrary/issues/130 >>> [4] https://github.com/internetarchive/openlibrary/issues/144 >>> [5] http://inspector.sindice.com/ >>> [6] >>> http://inspector.sindice.com/inspect?url=http%3A%2F%2Fopenlibrary.org%2Fworks%2FOL15120805W.rdf&content=&contentType=auto >>> _______________________________________________ >>> Ol-tech mailing list >>> [email protected] >>> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >>> To unsubscribe from this mailing list, send email to >>> [email protected] >> >> -- >> Karen Coyle >> [email protected] http://kcoyle.net >> ph: 1-510-540-7596 >> m: 1-510-435-8234 >> skype: kcoylenet >> _______________________________________________ >> Ol-tech mailing list >> [email protected] >> http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech >> To unsubscribe from this mailing list, send email to >> [email protected] -- Karen Coyle [email protected] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
