RE: [model] Proposal: Allow motivatedBy on SpecificResource

One more example from me to illustrate what I see as the slippery slope in modifying out data model to allow body-level motivations, even in what initially look to be straightforward copy-edit cases. 

 

Scenario:

 

*         A document being reviewed refers to an individual as ‘Julia’ in paragraph 2, but refers to same individual as ‘Julie’ in paragraphs 4 and 7. (The body-level motivations given below are made up for purposes of this illustration.)

 

*         Editor A, creates an annotation A1 with body1 “The string ‘Julie’ should be replaced by the string ‘Julia’.” Body1 has a body-specific motivation of edit-replace. This same annotation includes body2, with a motivation of edit-rationale, “This correction is warranted because the author referred to the individual as ‘Julia’ in paragraph 2.”  What are the targets of this annotation? Body1 is about the string ‘Julie’ in p4 and p7 – i.e., what needs to be edited, but really not about the string ‘Julia’ in p2. But body2 references the string ‘Julia’ in p2 directly, so a third target must be added to the annotation to support body2. But now we have a condition that violates 3.2.9 of our Data Model, “Each Body is considered to be equally related to each Target individually, rather than the complete set of Targets.” 

 

*         Continuing: subsequently Editor B, the one who gets to decide whether to implement the proposed copy edit, doesn’t think the rationale provided as part of annotation A1 is sufficient, so she does further research, calls the individual involved and confirms that the individual does indeed go by the name ‘Julia’ (even though, oddly enough, the name on her birth certificate is Margaret – go figure). 

So, to preserve provenance, Editor B now wants to create an annotation A2 with body1 (motivation of accept-edit-replace) “Accept edit-replace action proposed in A1”, body2 (motivation of reject-edit-rationale) “The edit-rationale offered in A1 is insufficient”, and body3 (motivation of action-rationale) “Confirmed with individual the name she uses is Julia.” The conflation of the edit-replace body and edit-rationale body in a single annotation has complicated taking subsequent action.  In theory body1 and body2 of annotation A2 target different parts of A1.  Body3 of A2 is kind of about body1 of A1, but mostly about body1 of A2.  The computer will have a difficult time following this logic from the Annotation RDF graphs – which limits the potential for subsequent fine-grained analyses of copy-editing practices that a publishing house might want to do.  If the rationales and accept/reject actions from an ontology rather than just plain text strings, the benefits for analyses of workflows and practices and collation of different classes of edits are diminished and you also still have the resource/specificResource open world issues that Rob outlined in an adjacent thread. 

 

In my mind, allowing body-level motivations, at least for the use cases so far proposed, is simply a way to conflate what should be separate annotation graphs.  A rationale has been suggested somewhere during these discussions that having to generate, post and retrieve multiple annotations pertaining to a proposed copy-edit action adversely impacts performance, reduces robustness and/or is less convenient. But to me, if this is really a serious problem, better places to look for a fix would be in the protocol and/or our client-side API, rather than in the data model.  

 

For example, should the protocol have a way of allowing posting of multiple (related or chained) annotations in a single transaction? (Does it already?) Or alternatively should the protocol have a transact / commit approach such as is still used in many database-driven applications – the transaction is not complete (not committed) until both AnnoX and AnnoY have been received by the server? (I think I might prefer the former, but we probably need to consider supporting at least one of these approaches – there are other use cases.) We haven’t gotten as far on the client-side API, but when a resource or resource segment has been annotated multiple times there is already an obvious need to retrieve these multiple annotations efficiently. This need will apply in the copy edit use case regardless – e.g., I need both the proposed correction and the subsequent decision to accept or reject. So I would suggest we should be thinking of ways to facilitate this optimization.

 

Anyway, I don’t want to flog a dead horse, but since Doug asked directly about slippery slopes, I did want to elaborate on the trouble we might get ourselves into if we allow multiple bodies that relate to multiple targets and to each other in substantively different ways.  I still do think there is a slippery slope potential here. 

 

Thanks,

 

Tim Cole

 

From: Salisbury, Davis - Hoboken [mailto:dsalisbury@wiley.com] 
Sent: Thursday, June 18, 2015 12:14 PM
To: Randall Leeds; Robert Sanderson; Chris Birk
Cc: Jacob Jett; Doug Schepers; Web Annotation; ColeTimothy W
Subject: RE: [model] Proposal: Allow motivatedBy on SpecificResource

 

Thanks Randall. I can see that the comment does not necessarily stand alone in reference to the target, and that yes in this specific case the comment is really adding context/justification for the edit, as you note. My thought was that it was possible to consider that both are still about the target. In my possibly fuzzy thinking the comment is not necessarily only about the edit text, but still about the targeted resource as well.

 

In  light of Rob’s “Why Motivations cannot be on Bodies” email I will defer and let others weigh in here. Allowing motivatedBy on specific resources seems like an OK possible solution, and more in line with the use case in my mind than creating a separate annotation just to provide a comment/context for the body of another.

 

Davis

 

From: Randall Leeds [mailto:randall@bleeds.info] 
Sent: Thursday, June 18, 2015 12:22 PM
To: Salisbury, Davis - Hoboken; Robert Sanderson; Chris Birk
Cc: Jacob Jett; Doug Schepers; Web Annotation; ColeTimothy W
Subject: Re: [model] Proposal: Allow motivatedBy on SpecificResource

 

If the motivating (hehehe) use case for this thread that one might have a comment justifying an edit isn't it simply semantically more correct to have the comment be part of a separate annotation? Otherwise, the comment is, by the definition of which Rob has reminded us, about the target. Furthermore, the comment doesn't stand alone in reference to the target if it actually means to describe the reason for including the other body.

 

On Thu, Jun 18, 2015, 09:09 Salisbury, Davis - Hoboken <dsalisbury@wiley.com <mailto:dsalisbury@wiley.com> > wrote:

One thing that may prove I am missing the point here, but that seems somewhat true (to me): does having the two bodies here—one with the edit itself, and one with a comment about the edit—preclude both bodies still being about the target? I know that the annotator in this use case is primarily concerned with providing rationale for the edit (or at least in some instances that is the proposed intent), the comment is still about the target, which is an error that needs to potentially be edited, is it not?

 

Davis

 

From: Robert Sanderson [mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com> ] 
Sent: Thursday, June 18, 2015 12:01 PM
To: Chris Birk
Cc: Jacob Jett; Doug Schepers; Web Annotation; ColeTimothy W
Subject: Re: [model] Proposal: Allow motivatedBy on SpecificResource

 

 

Bodies are explicitly independent. The data model says ...

 

http://www.w3.org/TR/annotation-model/#multiple-bodies-or-targets <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23multiple-2Dbodies-2Dor-2Dtargets&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=e9KfwugRmb6kH_-NpA3AxZaVrG4PAMUG2-g0ComW6sg&e=> 

 

Each Body is considered to be equally related to each Target individually, rather than the complete set of Targets. This construction may be used so long as dropping any of the Bodies or Targets would not invalidate the Annotation's meaning.

 

(More later, but wanted to prevent further speculation that could easily be avoided)

 

Rob

 

 

On Thu, Jun 18, 2015 at 8:55 AM, Chris Birk <cmbirk@gmail.com <mailto:cmbirk@gmail.com> > wrote:

That being said, if the bodies are assumed to be independent, then Jacob’s argument holds true that a comment must annotate the edit.

 

I strongly agree with the fact that one of the strongest aspects of the annotation model is that the annotation is in some way “about” the target, and that the comment should be an annotation on the edit.  If someone “resolves” ( if we decide to have some concept of resolution ) the edit, the comment cannot stand alone.


- Chris 

@cmbirk

(317) 418-9384 <tel:%28317%29%20418-9384>  

 

On Thu, Jun 18, 2015 at 10:04 AM, Jacob Jett <jjett2@illinois.edu <mailto:jjett2@illinois.edu> > wrote:

Hi Doug,

 

This is an issue we discussed in the community group to some length. I'll try to address your points in-line below.

 

On Thu, Jun 18, 2015 at 2:24 AM, Doug Schepers <schepers@w3.org <mailto:schepers@w3.org> > wrote:

Hi, Tim, Rob–

On 6/17/15 12:47 PM, Timothy Cole wrote:

Rob-

Consistent with Ray’s comments on today’s call about the copy-edit
use case, I think your use cases are better addressed by separate
annotations rather than by the added complications of motivations
added to annotation bodies.


Is that really what Ray was saying? I understood him differently. In the
past, he's argued for having multiple bodies in the same annotation,
each with its own motivation [1].

 

You're right, Ray has argued for multiple body annotations in the past but, that was not my understanding of what he was saying yesterday. The problem is ambiguity. People are well equipped to handle ambiguities and our natural language is loaded with features that exploit them. Machines are ill-equipped to manage them.

 

 

As you correctly point out, at the very least to allow motivation on
the body you would have to create your bodies as SpecificResources
which is an additional complication. I would argue that this is true
even if the body is textual, i.e., since the text string is not
inherently a replacement except in the context of the annotation
(though I accept this is a nuance we could probably ignore without
much harm).


I agree that requiring a SpecificResource as a body is an additional
complication; I would argue that in the default case, we shouldn't need
that, even if we include a separate motivation on each body.

To Doug’s point about keeping simple use cases simple, it is much
simpler from a modeling perspective to have one annotation which is
the correction itself and another annotation (as needed) that
explains the rationale for the correction.


I'm not sure I agree that it is simpler, nor that it matches expectations.

 

I'm not certain what you're going for with expectations here. If there is a notion that a user could just load up a bunch of annotations into onto a single target through a single oa:Annotation node, then as this discussion highlights, the roles that the individual bodies play are ambiguous to the machine. 

 

I know we want to do this for the sake of efficiencies. If I have a bunch of tags to apply to a single target, it's quicker and easier to just wrap them up into one annotation. This works okay when I have a single motivation that describes the role that all of the bodies are playing.

 

Let's assume each annotation is a distinct document, not just a data
structure. From a storage, sharing, and client perspective, splitting those up into separate documents seems like a bad idea, and doesn't seem like it would capture the intent of the annotator, who thought they were making a single annotation.

 

This is quite a stretch. We actually have no way of capturing annotator intentions. They might be annotating simply because they're feeling contrary. 

 

In the case of annotating in the context of editorial workflows, Bob Morris and Phil Morris in the CG face-to-face meetings both argued that having a distinct expectation property is significantly helpful (and IMO necessary) to capture annotator intentions (inasmuch as is possible without some kind of thought police) and at the very least can be leveraged by machines to execute any desired edits.

 

Unfortunately this use case is something of a slippery slope for us. In the CG, no one wanted a property that expressed expectations because it further complicated what was (and is) already a complex model. If we need to fully integrate the editorial use case then we probably need to re-examine this CG decision. 

 

In simple copy-edit cases, the second annotation would rarely be
needed (more specific motivations on the annotation might be needed
– e.g., edit-insertion, edit-deletion, edit-replacement,
edit-transpose, …). When the second annotation is needed, e.g., a
comment about supporting the edit, keeping it separate from the
copy-edit annotation would allow for the use a multi-target
annotations, e.g., “these 10 proposed edits (each its own
annotation) were all needed because….” – that’s a single annotation
targeting the ten copy-edit annotations.


I agree that you can model it this way, if you're applying a single
annotation needs to target multiple other annotations, but I also think
that you should be able to maintain a simple association (multiple
bodies) for the more common case when you have a single body with an
"edit" motivation and an accompanying body with a "comment" motivation,
both applying to the same target.

 

I'm not sure what we're going for with this kind of structure. What is my annotation consuming client supposed to do with it? How am I supposed to interpret an annotation that both edits the target and comments on the target?

 

I mean, it seems clear that for the sake of efficiency we have clearly let a bunch of semantic infelicities creep in. If I understand the intention correctly, it is not the case that the annotator is commenting on the target; rather, the intention was to comment on the act of editing, was it not? 

 

Because of the way the annotation model is built, there's no way to actually get that interpretation out of the annotation, even if we have a motivation on each body. At best the machine will see the following "body A an edit annotating target 1", "body B a comment annotating target 1". There is no way to get the desired interpretation -- "body B a comment annotating [edit annotating target 1]"

 

As Ray and Tim both point out, the only way to make the semantics work is if the comment is a separate annotation targeting the annotation that asserts the edit.

 


I understand that that may introduce some ambiguous entailment about
whether the "comment" body is meant to apply to the "edit" body, the
target, or both. But I believe that in many cases, that annotation
author's intent is subject to multiple interpretations (e.g. "I'm
suggesting the target be changed, because…", "I'm suggesting this
replacement be used, because…", and "I'm suggesting the target be
changed to this specific replacement, because…" are all intrinsic and
valid interpretations; human language and motivation is messy, and no
amount of prescriptive modeling will change that).

And of course that copy-edit annotations are modeled as individual
annotation is easily hidden from the human editor by the interface
when appropriate – e.g., change all occurrences of Rbb to Rob looks
to the human editor like a single copy-edit in the interface. The
fact that there is a Rbb to Rob copy-edit annotation for each of the
10 occurrences of Rbb in the document is handled by the software
behind the interface.


Wouldn't that be better modeled as a single annotation, with a single
"edit" body and 10 different targets?

 

Yes. You still cannot use a second body in that annotation to comment on the editing because the act of editing is not the target of that body. The semantics only work if the comment is an annotation targeting the "edit" annotation that has 10 different targets.

 

Obviously, it depends on the workflow, and what the tool lets you do.

(A sophisticated copy-edit annotation tool might let you search the text
and automatically create targets for all instances of a word or phrase;
for that matter, it might even offer a corrected spelling, or find
misspelled word for evaluation… but I digress.)

As for the other use cases you mention, I think the same logic
applies:

* A single annotation that has both tags and a comment about the
target is really a tagging annotation and commenting annotation or a
tagging annotation and comment annotation on the tagging annotation.
(Note in this case that there is a nuanced distinction possible by
keeping the annotations separate that is not possible when you
conflate.)


There's also a nuanced distinction possible by keeping the annotations
together that is not possible when you separate them. Again, true intent
is hard to nail down.

 

As noted, we have no way to prognosticate on intentions. At best we can make some assumptions but, assumptions are dangerous things. Seems like there's a popular idiom for this...

 

If we want to capture and remark upon annotator intentions (beyond simple motivations) then we need additional properties. Again this article (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3817185/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ncbi.nlm.nih.gov_pmc_articles_PMC3817185_&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=_O9FIDiQx39_kLcVu51bgnCx_sbaSsfnHzHsdLHa4qg&e=> ) seems highly pertinent. Not only have the authors extended the CG annotation model with an expectation property that describes what the workflow is supposed to do with the edit but they also have a property that captures evidence that supports why the edit is necessary.

 

Ultimately though, the addition of more properties means the model will become more complicated...so we should probably tread lightly and consider to what extent we can really support editorial workflows and what should be left for them to add to the model through extensions.

 

 

* A single annotation that has a moderation up-vote, and a comment
explaining why the moderation should be considered is an up-vote
annotation and an explanation annotation on the up-vote annotation
(note, not an explanation annotation targeting what is being voted
on).


Again, I don't think it's always simple to make that judgment, at least not without requiring the annotator to jump through too many hoops.

 

Here's the crux of the matter. Efficiency (or --forgive me for being blunt-- laziness). Sometimes the annotator has to jump through hoops or they simply can't have all of the functionality that they desire. We could conflate the edit and the comment but then it is never the case that the comment is actually about the edit. The way multiple bodies (and single bodies too) work, is that THEY ARE ALWAYS ABOUT THE TARGET. Sorry, I don't think that I could stress that enough. It's the primary feature of the annotation model. A body is "about" the target (in some way, even if that isn't a topical way).

 

The use case you describe with two bodies possessing different motivations, even though the motivations are different, the bodies still apply to the same target. If they don't then what you're describing does not conform to the annotation model (and I personally find the semantics weird -- I'm no longer sure what it's trying to tell me; there's an edit of the target and a comment about the target but not really because it's secretly about the edit...but the model doesn't support that interpretation of the graph's chain of assertions...)

 

If I have a single annotation with a comment and a tag, is my tag about the target content or about my comment, or both (or neither, and I'm irrelevantly expressing my mood)? It depends on my specific intent.

 

Actually, it must be about the target. That's the primary tenant of the model...

 

...and as for specific intentions...where was my crystal ball again?

 

Yes, we could allow the user to control that, but can you imagine how user-hostile such a UI/UX would have to be? People don't tend to like pedantic user interfaces.

Finally, my reason for mentioning more complex copy editing use
cases was meant to invoke the slippery slope argument, if we make a
model change to allow annotations on bodies to make our annotations
more human-readable and to save on the number of annotations minted
in order to address simple use cases, we can anticipate that users
will abuse this capacity to handle arbitrarily complex use cases
conflating what should be distinct annotations.  There’s no
reasonable way to preclude this and I just don’t yet see the carrot
for introducing motivation at the body level – but I’m willing to be
convinced if someone can come up with the use case that can only be
handled by motivation on the body (rather than separation into
separate annotations with motivation on the annotation).


Can you explain what slippery slope you're talking about? What kind of arbitrarily complex use cases do you have in mind?

The slippery slope is two fold.

 

1) If the annotation model is to work as you propose then we can no longer rely on bodies being "about" the targets. This implies that the following sections (http://www.w3.org/TR/annotation-model/#introduction <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23introduction&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=iqNKQJ0FBo2THmOIk8kGsChbD4z_lIY4qvroHdVvOQ0&e=> ) and (http://www.w3.org/TR/annotation-model/#annotation <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23annotation&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=dICZLNq3vyN0TPrgTcI5v78KkXV2RFcp_SdUNhn8Jjs&e=> ) will require major revisions with regards to their scoping statements and explanations.

 

2) The editorial workflow is a use case we must accommodate then it has been adequately demonstrated (here (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3817185/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ncbi.nlm.nih.gov_pmc_articles_PMC3817185_&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=_O9FIDiQx39_kLcVu51bgnCx_sbaSsfnHzHsdLHa4qg&e=> ) and elsewhere) that additional properties on multiple entities in the model are likely necessary.

 


(Keep reading for my replies to Rob…)

-Tim Cole

*From:*Robert Sanderson [mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com> ] *Sent:*
Tuesday, June 16, 2015 3:55 PM *To:* Web Annotation *Subject:*
[model] Proposal: Allow motivatedBy on SpecificResource

Currently the motivation for an Annotation is associated only with
the Annotation, however the different bodies of a single Annotation
may have different motivations for their inclusion.


That's my goal, yes.

The current model:
http://www.w3.org/TR/annotation-model/#motivations <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23motivations&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=jk1rm_smc_EZeIG-0kLAsRlmfFWaNJcCwwu8LXQxOqM&e=> 

Use cases that have come up include:

* A single annotation that has a body that is the replacement edit
for the target, and a body that is a comment about the change

* Motivations cannot be associated directly with the body resource,
as the body may be used in multiple annotations, with different
motivations. They might also be the target of a different
Annotation, and motivation is exclusively tied to the Annotation that
asserts it.

Therefore, a SpecificResource is needed to stand for the resource in
the context of the Annotation.


Can you explain the necessity for this a bit more?

 

If the body is a b-node (i.e., a string of text) then it'll have a different identity in every annotation...that means you'd have to annotate every instance. Whereas if it's a specific resource then it has one unique global identity and you need only annotate it once.

 

We should definitely enable the case where someone can reference the same body in multiple annotations, but not at the expense of complicating the most common case, where a body applies to a single annotation.

Isn't there some approach that would allow the body to have a motivation directly, while also allowing a SpecificResource to model a more complex use case?

By associating the Motivation with the SpecificResource we would be
clear regarding which resource the motivation applies to.

If the Annotation and a SpecificResource both assert a motivation,
the SpecificResource's motivation would take precedence for its
source resource.


Couldn't this precedence of ordering (in CSS, this is called the "specificity of the cascade") equally apply to a body, not just a SpecificResource?

[1] https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0056.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_public-2Dannotation_2015Mar_0056.html&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=8OILMOkVQaP_85IwuDQYNS-rAG06gQJf0UBrABT7H6s&e=> 

Regards–
–Doug

 

 

Apologies for sounding flip. What is being suggested isn't just an added feature to the model to service a single use case. It has direct implications for the model's core semantics, that the body's content can reliably be interpreted as being "about" the target's content in some manner. If some of the bodies are actually about other bodies or the relationship between those bodies and the targets, then the model's semantics are no longer reliable...

 

Regards,

 

Jacob

 

 

This would allow, for example:

<> a oa:Annotation ;

oa:hasBody _:tag1sr, _:comment1sr ;

oa:hasTarget <http://example.org/paris.jpg <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.org_paris.jpg&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=u8PVw6FVOyrHgvQMdsYUIaJQIM-tHXw1M89w9-X9_JQ&s=2lJ3OoPpssV5F4jo6mKW5R5bfJw2cSqqU4czUyHgPmE&e=>  >

.


_:tag1sr a oa:SpecificResource ;

oa:motivatedBy oa:tagging ;

oa:hasSource _:tag1 .

_:tag1 a oa:EmbeddedContent ;

rdf:value "paris" .

_:comment1sr a oa:SpecificResource ;

oa:motivatedBy oa:commenting ;

oa:hasSource _:comment1 .

_:comment1 a oa:EmbeddedContent ;

rdf:value "I think this is photo is of Paris because I can see the
Eiffel Tower."

Rob


--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

 

 

 





 

-- 

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305