On 6/2/2010 9:04 AM, Karen Coyle wrote: [snip]
> The problem I see with RDA's Person is > the problem I see with all of RDA which is that it is tied to FRBR > entities as classes, so if you use it you can't really get far from > FRBR. I fail to see why this is a problem. I though OL was trying to move to a FRBR model in its database. Of course, it is almost always a mistake to try to build a database model from a data transfer format. Whether the source, or the sink, of a data record is XML, MARC, XML:RDF, JSON, or any other arbitrary format should be largely irrelevant. As Bill Dueber recently pointed out, "[a]nyone advocating or dismissing a data model based on the data structure or serialization most-often associated with that model is missing the goddamn point." Whether you want an author expressed as a foaf:Person, or a dc:creator, a generic rdf:description, or even a JSON text object depends on the consumer of the data. If the database has been designed correctly, any of these transfer formats can be easily generated. So before any questions about how best to represent a person in RDF can be addressed, you should try to find out who will be consuming the data, and what their expectations are. If there are no existing applications out there designed to consume data in a know format, or which can easily be modified to consume data in a slightly altered format, then it doesn't matter how the data is serialized; a new application will have to be written to consume the data anyway--pick anything you like that carries all the data you need. If I were writing a new application to consume OL data, I would use the JSON object; it's all UTF-8 so it's easy to parse, and so far it's the only interface around that guaranteed to furnish /all/ the data currently held by OL. Of course, there remains the question as to just how much effort should be put into defining this interface, as those who would be consuming it are not the primary target audience for OL. I would echo the suggestions of several others in saying OL should take all the time it's spending on creating Yet Another API, and spend it instead on measures to increase the quality of the existing data. _______________________________________________ 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]
