- From: Thomas Baker <tbaker@tbaker.de>
- Date: Fri, 21 Jan 2011 08:48:43 -0500
- To: "gordon@gordondunsire.com" <gordon@gordondunsire.com>
- Cc: Karen Coyle <kcoyle@kcoyle.net>, Mark van Assem <mark@cs.vu.nl>, public-xg-lld@w3.org
On Fri, Jan 21, 2011 at 09:46:07AM +0000, Gordon Dunsire wrote: > Librarians are used to seeing this record with Z substituted by an appropriate > literal (usually something akin to the value of the corresponding > skos:prefLabel): > > :R :p1 "text". > :R :p2 <:Z skos:prefLabel> "label". // this touches on the data packaging issue > (btw, is there a syntax to show a triple chain like this?) One easy way: :R :p2 :Z :Z skos:prefLabel "label" > So there are different points-of-view, and it is probably always possible to > constrain a "record" to triples with one, and only one, subject. Does RDF let us > have the cake, and eat it? One could locally decide that all "records" produced must be limited to statements about one resource. In terms of the DCMI Abstract Model (DCAM) [1], a "record" would not encompass an entire Description Set, but only one Description. I invoke DCAM here precisely because its design after 2003 was a response to the limitations of "flat" (i.e. single-resource) Dublin Core descriptions -- i.e., by the modeling implications of needs as simple as putting authors' contact information into the description of a conference paper. As I see it, records are a packaging mechanism useful for managing data and tracking provenance. A particular RDF graph can consist of multiple interconnected subjects, and there may be good reasons to record that multi-entity graph in a record. Yes, one could impose a rule that the graph recorded in a record consist entirely of statements with the same subject, but practical needs for shoehorning additional information into records could tempt people to come up with workarounds that are messy from a modeling point of view. Tom [1] http://www.dublincore.org/documents/abstract-model/ -- Tom Baker <tbaker@tbaker.de>
Received on Friday, 21 January 2011 13:49:24 UTC