I changed the subject a bit because I think the RDF view is constrained by the underlying datamodel.
On 1 February 2012 15:55, Karen Coyle <[email protected]> wrote: > > > On 1/31/12 5:05 PM, Ben Companjen wrote: >> >> Hi Karen, >> >> Thanks for your comment, but I am not sure about saying "these (few) >> non-persons can be foaf:Persons". This may be an issue that cannot be >> easily fixed in the RDF views though. >> Is there a way in the system (and database) to say Rijksmuseum Twenthe >> is not a person or to specifically say it is an organization? > > > There isn't now in OL. As I said, the decision was to put non-Person > creators in contributor. However, that was based on library data, which does > distinguish between persons and corporate entities. I don't know where the > corporate entities as creators is coming from - perhaps from Amazon? (There > also was a batch of library data that didn't make the appropriate > distinction.) If so, there may not be a way to tell which they are. Ross > says that there are many corporate bodies in the creator field... so I can > only imagine that they come in from one of the major data sources. I looked at the underlying type schema at http://openlibrary.org/type and it seems that there is no "contributor" type. There is /type/edition/contributions (an array of strings), which may be where contributors are stored when I manually enter translators and designers, though how exactly the role and contributor name would be stored in this string is unclear to me. When looking at some MARC records for http://openlibrary.org/books/OL21322149M/Mies_van_der_Rohe (author "The Museum of Modern Art"), indeed MoMA is in the 110 field (I learned yesterday that field is for corporate entities) and the author is in the "by statement", shown by OL too, as "by Philip C. Johnson." I don't want to accuse anybody, but this leads me to think perhaps ImportBot doesn't know how to import this. Or maybe this record was imported (November 1, 2008) before the decision was made? > > Following the general practice of trying not to lose any specificity, it > would then be best: > - where persons are identified as persons, keep that information in the OL > data. There would still be some stray non-persons that are mis-coded in the > input data. > - where corporate entities are identified as such, code them as such in OL, > rather than putting them in collaborator, which also gets personal names. > - where it isn't possible to distinguish, give them a general "agent" > designation in OL > Searching for authors with "museum" in the name yields 5608 results, many having over 100 works attached :) The work type doesn't have a contributors/collaborators field at all. > This would mean adding some fields to OL. However, I really do think that > person-hood is an important concept and one worth keeping. It's a bit > complex because it means having two kinds of "collaborator" - person and > corporate entity. Perhaps there could be a "responsible organization" added > to take the known corporate entities? > Agreed, more fields are needed. /type/author is clearly meant for people (with properties like birthdate, personal name) and that should stay. >From a linked data perspective it would be nice if corporate entities (including publishers, although not all publishers are corporate entities) are not just strings, but real entities. > >> When >> there is, it is easy to change the RDF template accordingly. Of course >> I can revert foaf:Agent to foaf:Person in my changeset, but in these >> special cases the RDF will be 'wrong'. My proposal may 'just' be less >> precise, as foaf:Person is a subclass of foaf:Agent, unless other >> properties are used that only apply to persons. >> I don't know of any rule / guideline that says organizations should be >> added as collaborators instead of creators, or of a way to enter the >> information this way. > > > That was built into the automated import process. There was a reluctance to > provide "rules" for user input to OL, and I think there may have been the > assumption that few users would consider corporate bodies as authors. That's > something that is common in library data but that you don't see in other > environments. When I look up "Rijksmuseum Twenthe" in Amazon it does > sometimes appear as an author, but only in third-party entries, and those > use the library heading "Rijksmuseum Twenthe (Netherlands)" so I assume the > data was copied from library records. Amazon itself does not appear to use > corporate bodies as authors. > I would only consider putting a corporate body in the author field if a human author is not mentioned in the book at all, which is very rarely the case. > >> >> What exactly do you mean by linking? > > > Linking as in "linked data." Linking to other person information "in the > cloud," such as the Virtual International Authority File (VIAF) [1] or > DBPedia. Since OL is a large store of bibliographic data, others may want to > link to persons in OL to pick up bibliographic data with that person as > creator. This is more direct if these can be identified using 'foaf:Person'. > I'm not sure that those linking will know to link personal names in their > data to foaf:Agent in OL. > > BTW, linking to VIAF may be a way to disambiguate the corporate bodies from > the persons, since they will be coded differently in that data. VIAF could be useful for disambiguation, but there is no obvious way to enter a VIAF ID (or any other URI for a person) in an OL record. Is this what http://openlibrary.org/type/author/uris is for? That could make Open Library less isolated in the LOD cloud [2]. I have added links to VIAF pages to a few authors, but they are probably in /type/author/links. It seems VIAF has at least 4 entries for the MoMA (New York), by the way. A (software) agent consuming RDF should not have a hard time figuring out that a foaf:Person in its knowledge base is the same as a foaf:Agent in Open Library, so I don't think this is the best reason to not change to foaf:Agent - not losing specificity is a better reason :) > > kc > > [1] http://viaf.org > [2] http://richard.cyganiak.de/2007/10/lod/lod-datasets_2011-09-19_colored.html > >> >> If you have more remarks, I'd like to hear them too. :) >> >> Regards, >> >> Ben _______________________________________________ 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]
