Sorry, I now realize that I was interpreting "serialization" too 
narrowly - and Tom's statement about "serializing DSP" makes sense. I 
think the rest of this message is still coherent, however. Once again, 
apologies for the length, not only of this message but of the entire 
conversation on my part. I feel like we've got apples and oranges here, 
and I, for one, am trying to overcome my own monoculture.

kc

On 8/16/12 9:54 AM, Karen Coyle wrote:
> I apologize for the length of this post. I just can't seem to make it
> more concise.
>
> On 8/16/12 6:41 AM, Thomas Baker wrote:
>
>> If a DSP is a set of templates with specified constraints -- a
>> Description Set
>> template, which encloses one or more Description Templates, each of which
>> encloses one or more Statement Templates, each of which is described with
>> various Resource, Property, and Value constraints, it is not
>> immediately clear
>> to my why one _couldn't_ simply say that the order of templates
>> described in
>> that Description Set Profile document is meaningful.  When serializing
>> that DSP
>> to RDF triples, the order would be lost.  But when serializing to another
>> document format, such as XML, or to an ISBD Publication String, I see
>> no reason
>> the order could not be retained.
>
> Tom, I may be mistaken, but I think this still conflates the DSP and
> instance data. The DSP, in my mind, plays the role of an XML schema, but
> for DCAM-compliant data. (Which also means RDF-compliant, right? or
> wrong?) There's a difference between the templates as defined in the
> DSP, and the instance data, which is where repetition that is allowed in
> the DSP actually takes place.
>
> A DSP can specify that a statement is (or is not) repeatable, mandatory,
> etc. But the DSP itself is not serialized, it is the instance data that
> is serialized. So if a DSP provides for a statement that is "paragraph"
> and is repeatable, the repetition takes place in the instance data. A
> paragraph template of:
>
> paragraphTemplate
> min=0, max=unbounded
>   - paragraphText (literal)
>     min=1, max=1
>
> just gives you an undistinguished group of paragraphs in instance data.
> The only way to maintain order is to wrap them in something like XML.
> But my interest is in triples.
>
> Where order matters, to maintain order in the instance data, the DSP
> would need to define a statement template something like:
>
> paragraphTemplate
> min=0, max=unbounded
>   - paragraphOrder
>     min=1, max=1
>   - paragraphText
>     min=1, max=1
>
> The instance data would then be:
>
> paragraph
>   - "1"
>   - "First paragraph"
>
> paragraph
>   - "2"
>   - "Second paragraph"
>
> This is obviously do-able, and I believe would work in an RDF
> environment as these would be graphs. Another example would be tables of
> contents, each statement of which consists of:
>
> author, title, startPage
>
> This could be seen as:
>
> ToCDSPTemplate
> min=0, max=1
> ToCStatement
> min=1, max=unbounded
>   - author
>     min=1, max=3
>   - title
>     min=1, max=1
>   - startPage
>     min=1, max=1
>
> This would give you a repeatable template for toc's, with three
> statements in the DSP. But generally you want to display toc's in order,
> so an ordering data element would be needed here, as would another
> ordering to keep the up-to-three authors in order. (This latter order is
> sometimes important.) So you would need a solution like the one for
> paragraphs.
>
> Much of what is in library data is repeatable elements, and in some
> cases order matters. In other cases, order does not matter and a display
> program can construct meaningful displays.
>
> Any time you have repeatable patterns where order matters, you will need
> an ordering mechanism. You could also define a serialization (like XML)
> that treats your "record" as a single string, thus maintaining the order
> of all that is within the string. I believe that the SES that Jon is
> proposing is conceptually like an XML document, in that it is a single
> string with meaningful parts and order of parts within it. The SES, as I
> read it, is a clever attempt to make strings into things.
>
> That said, I will go on record as saying that in terms of "converting"
> library cataloging documents (e.g. ISBD or MARC records) into linked
> data, I prefer the choice made by OCLC, which has added RDFa to its
> catalog data displays, and does not attempt to represent the entire
> catalog document as linked data. I think this is in keeping with the
> intention of linked data, which has been described as a way to define
> the data encapsulated in documents. The WorldCat RDFa is derived
> programmatically, and does not attempt to replicate the entire content
> of the catalog record. Moving from library cataloging (as it is done
> today) to linked data will be lossy, just as adding microformat data to
> HTML is. The catalog data that is created today is an artifact that
> dates back at least to 1830, and it really is time for libraries to
> re-conceptualize how they catalog in terms of "data" not "documents."
>
> Are we in a quagmire if we try to replicate all of library catalog data
> in RDF? There may be a solution, but I have serious doubts about the
> value and return on the effort. If you must drag library catalog data
> into the linked data space, the "pass them as strings" solution is not
> the worst. However, I would treat them as literals, not structured data,
> and let applications deal with any internal structure "up the stack."
>
> kc
>
>
>
>>
>> Tom
>>
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet