specify how record collections reference the records they contain

[stoicflame]

We need to define how record collections specify their contents.

The simplest solution would be to just have the collection contain a list of links to their records:

<collection>
  <title>...</title>
  ...
  <record rdf:resource="..."/>
  <record rdf:resource="..."/>
  <record rdf:resource="..."/>
  ...
</collection>

But is that adequate? What if there are millions of records in the collection? Does the record list need to be split up? If the answer is "no, we'll just deal with big collections", then we can just go with this suggestion. It's definitely the most clear.

Another option, just mentioned here for the sake of discussion, is to do it kinda like RDF specifies with the rdf:Collection construct, which constructs itself in a linked-list kind of a way. So it would look kinda like:

<collection>
  <title>...</title>
  ...
  <records rdf:resource="#myrecordlist"/>
  ...
</collection>

<rdf:Description rdf:nodeID="myrecordlist"> 
   <rdf:first rdf:resource="..."/>
   <rdf:rest rdf:nodeID="#myrecordlist2"/> 
</rdf:Description>

<rdf:Description rdf:nodeID="myrecordlist2"> 
   <rdf:first rdf:resource="..."/>
   <rdf:rest rdf:nodeID="#myrecordlist3"/> 
</rdf:Description>

<rdf:Description rdf:nodeID="myrecordlist3"> 
   <rdf:first rdf:resource="..."/>
   <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> 
</rdf:Description>

Thoughts and comments are welcome.

[carpentermp]

I don't really understand the 2nd option very well so all I can say about it is that it seems more verbose, so option 1 appeals more to me.

I suppose that for data exchange having the full list is fine, but not for a web service. A web service would need a way to page through the contents. Also, remember that record order is significant and that, in a web service, we need a way of efficiently moving from a given Record to the previous and next Record.

A couple of more things--in data exchange, a simple link to the contained resource is all you need, but in a web service you would probably want a little metadata, like:

• the GedcomX "type" of the contained resource (I guess you are defining a "RecordCollection" here, so that is known implicitly. If you continue down this path, you will need a type of collection for every type of thing that can be contained, e.g. "PersonCollection", "ImageCollection", "CollectionCollection", etc. In SoRD, we just had a generic Collection (we named it "Container" because some felt that "Collection" had a lot of baggage in the Genealogical community--a view I don't share. I like "Collection" better.) and put an attribute on the container to say what type of contents it had.
• the title (The title of a record would typically contain the name of the principal person(s) and the name of the Collection. This brings up a phenomenon I have noticed with hierarchical groupings of resources--Often, parts of the metadata of a resource come from the parent. For a record, you might say it's title is {collection-title} + {principal name}. When giving the title of the Records contained in a Collection, it is redundant to include the Collection title each time. However, when a Record is considered in isolation, the full title is useful. This can be the same for the "place" coverage as well. Perhaps the place of parent Collection is "Utah, United States" and each subcollection represents a different county e.g. "Carbon, Utah, United States". I have long thought that we ought to be able to express this type of dependency in the model.
• possibly the description

This metadata helps a "browser" of this data know something about the contained thing without necessarily having to fetch it to find out about it. We used "Container" for all types of things, including waypoints.

I suppose you could accomplish the need for content metadata by including, in the fetch of a Collection, summarized metadata descriptions for the contained resources.

[stoicflame]

Very good points.

I don't really understand the 2nd option very well so all I can say about it is that it seems more verbose, so option 1 appeals more to me.

It's just a "linked list" implementation where resources in the list contain the resource and a pointer (URI) to the "next" resource. The last resource "points to" null.

But I agree. Yuck.