- From: Timothy Cole <t-cole3@illinois.edu>
- Date: Mon, 3 Aug 2015 15:45:37 -0500
- To: "'Robert Sanderson'" <azaroth42@gmail.com>, "'Ivan Herman'" <ivan@w3.org>, "'Frederick Hirsch'" <w3c@fjhirsch.com>
- CC: "'W3C Public Annotation List'" <public-annotation@w3.org>
- Message-ID: <02a101d0ce2d$5b601ca0$122055e0$@illinois.edu>
Rob, Fredrick, Ivan, et al.-
I remain unconvinced that assigning a motivation or role to an Embedded Textual Body not being assigned a URI in the Annotation is bad RDF.
In my mind, if you don't give an Embedded Textual Body a URI (i.e., if you let it default to a blank node) then that Embedded Textual Body will not be reused outside the current Annotation, and therefore the role assigned to Embedded Textual Body in the context of the current annotation is the only role which this particular instance of the string will ever have. RDF inferencing is done on URIs, not on string values. Obviously it is a different matter if you are using a resource of any type identified with a de-referenceable URI.
But I may be wrong. Discussing these issues about multiple bodies / multiple annotations in the abstract is getting to be challenging. In an effort to better understand various options and their pros and cons, I needed to work through a few more complete concrete examples (see below, if interested, options discussed in no particular order). Others may have additional / better illustrations, but the question is are we are reaching consensus? If not, I wonder if we should take Doug's earlier suggestion from 10 July [1] to mount a wiki page (if this has been done, I couldn't find it) to which we can all contribute and then with this prep dedicate a call or two to this topic which touches on several key issues for us.
Or is everyone else satisfied that we are near consensus and ready to close this issue out on our next call?
[1] https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0115.html
Concrete examples – incomplete first draft:
Here's my first draft attempt at concrete illustrations (leaving out annotation provenance for the moment). There are almost certainly errors in these examples, and I'm sure I've left many more examples out. I stuck with json except for graph 1 where I also provide Turtle. Rather than try to correct and augment these examples in this email thread, the way to go *if there's enough interest* is to create a wiki page or the like where people can argue the details, correct mistakes and augment with additional examples. Would this be worthwhile to do?
Given an annotation such as this containing multiple bodies:
Graph 1: in JSON (and JSON-LD if you add our context)
{
"@id": "http://example.org/Anno1",
"@type": "oa:Annotation",
"body": [
"This sentence is an example of an amphibology and needs to be changed.",
"Piloting an airplane can be a dangerous thing to do."
],
"target": {
"@id": "http://example.org/Anno1#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
Graph 1B: same in Turtle, something like this (I will stay with JSON the rest of the way):
@prefix oa: <http://www.w3.org/ns/oa#> .
<http://example.org/Anno1>
a <http://www.w3.org/ns/oa#Annotation> ;
oa:hasBody "Piloting an airplane can be a dangerous thing to do.", "This sentence is an example of an amphibology and needs to be changed." ;
oa:hasTarget <http://example.org/Anno1#sptarget1> .
<http://example.org/Anno1#sptarget1>
a oa:SpecificResource ;
oa:hasSource <https://en.wikipedia.org/wiki/Syntactic_ambiguity> ;
oa:hasSelector [
a oa:TextQuoteSelector ;
oa:suffix "Either th" ;
oa:prefix "mountain?" ;
oa:exact "Flying planes can be dangerous."
] .
This is a reasonably simple starting point. As has been discussed the problem is that this graph does not differentiate between the 2 bodies, each of which clearly (to a human) has a different role in the annotation. (By the way, I admit to being unsure about the use of #sptarget1, especially given our reliance in the protocol document on LDP, but this, I think, is a different conversation, not relevant to the current concern. For the LDP system I was using to test, it was much easier to do it this way.)
***Option 1 - multiple annotations***
Recreate as 2 distinct annotations, each with its own motivation; reuse the specificResource target.
Graph 2A:
{
"@id": "http://example.org/Anno2A",
"@type": "oa:Annotation",
"motivation": "oa:commenting",
"body": "This sentence is an example of an amphibology and needs to be changed.",
"target": {
"@id": "http://example.org/Anno2A#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
Graph 2B:
{
"@id": "http://example.org/Anno2B",
"@type": "oa:Annotation",
"motivation": "oa:editing",
"body": "Piloting an airplane can be a dangerous thing to do.",
"target": {
"@id": "http://example.org/Anno2A#sptarget1",
"@type": "oa:SpecificResource"
}
}
The biggest drawback here is that I now have 2 separate annotations that were really created together by the agent. We've had discussions about Annotation Sets, and though not accommodated by our current model or protocol drafts, implementers are using Annotation Sets in practice. LDP patterns offer a way to group or cluster annotations, albeit not all that efficiently and requiring knowledge of Direct Containers (or Indirect Containers), an LDP feature that not everyone is choosing to implement. So for example, properly created, you could have this:
Graph 3A: An Annotation Set (as defined in some ontology which also defines the annotations predicate)
{
"@id": "http://example.org/rest/AnnoSet210",
"@type": "omy:AnnoSet",
"title": "A Set of Edit Annotations.",
"annotations": [
{
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2A"
},
{
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2B"
}
],
"contains": {
"@id": "http://example.org/rest/AnnoSet210/AC211"
}
}
Graph 3B: one annotation in the Set
{
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2A",
"@type": "oa:Annotation",
"motivation": "oa:commenting",
"body": "This sentence is an example of an amphibology and needs to be changed.",
"target": {
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2A#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
Graph 3C: the other annotation in the Set
{
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2B",
"@type": "oa:Annotation",
"motivation": "oa:editing",
"body": "Piloting an airplane can be a dangerous thing to do.",
"target": {
"@id": "http://example.org/rest/AnnoSet210/AC211/Anno2A#sptarget1",
"@type": "oa:SpecificResource"
}
}
Each annotation (previously each body) can now be referenced on its own, which is good for many use cases. One glaring limitation -- LDP does not currently provide a way (that I know of) to post or get all of 3A, 3B, and 3C in a single HTTP request. Possibly we could define a best practice. There is also a 4th resource (the LDP Direct Container) involved which is not shown. This may be too much overhead. Still the annotation set concept is useful and is being used. There are other (non-LDP) ways to do Annotation Sets. Do we want to make any accommodation for Annotation Sets (e.g., add a class and predicate to our data model context)? If we did, this option might become more attractive. Note, that in an editing scenario, subsequent annotations, e.g., feedback from the author on the proposed edit, can be added to the set.
***Option 2 - body-level motivations***
Graph 1 can be rewritten with Embedded Textual Bodies or with SpecificResource Bodies, allowing implementers to express additional properties of the bodies, such as role or motivatedBy (illustrated below). Graph 4 below, using Embedded Textual Bodies, is inconsistent with the argument you have made that to express the role of a body you must always have a Specific Resource (see above).
Graph 4: Embedded Textual Bodies, @type oa:EmbeddedContent required (MUST), @type oa:SpecificResource, format & language encouraged (SHOULD):
{
"@id": "http://example.org/Anno1",
"@type": "oa:Annotation",
"body": [
{"@type": "oa:EmbeddedContent",
"role": "oa:commenting",
"value": "This sentence is an example of an amphibology and needs to be changed.",
"format": "text/plain",
"language": "en"
},
{"@type": "oa:EmbeddedContent",
"role": "oa:editing",
"value": "Piloting an airplane can be a dangerous thing to do.",
"format": "text/plain",
"language": "en"
}
],
"target": {
"@id": "http://example.org/Anno1#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
Graph 5: SpecificResource Bodies
{
"@id": "http://example.org/Anno1",
"@type": "oa:Annotation",
"body": [
{
"@type": "oa:SpecificResource",
"role": "oa:commenting",
"source": {
"@type": "oa:EmbeddedContent",
"value": "This sentence is an example of an amphibology and needs to be changed.",
"format": "text/plain",
"language": "en"}
},
{
"@type": "oa:SpecificResource",
"role": "oa:editing",
"source": {
"@type": "oa:EmbeddedContent",
"value": "Piloting an airplane can be a dangerous thing to do.",
"format": "text/plain",
"language": "en"}
}
],
"target": {
"@id": "http://example.org/Anno1#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
***Option 3 - specializations of the hasBody predicate***
This is probably the least extensible approach and creates problems for those not using RDF inferencing (which I would assume most implementers are not wanting to do), but it is also a rather straightforward approach. Assumes we add appropriate sub-properties of hasBody to our data model and context document. Your critique and rationale for not wanting to take this approach is here [2].
[2] https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0019.html
Graph 6
{
"@id": "http://example.org/Anno1",
"@type": "oa:Annotation",
"commentBody": "This sentence is an example of an amphibology and needs to be changed.",
"editBody": "Piloting an airplane can be a dangerous thing to do.",
"target": {
"@id": "http://example.org/Anno1#sptarget1",
"@type": "oa:SpecificResource",
"source": "https://en.wikipedia.org/wiki/Syntactic_ambiguity",
"selector": {
"@type": "oa:TextQuoteSelector",
"exact": "Flying planes can be dangerous.",
"prefix": "mountain?",
"suffix": "Either th"
}
}
}
There are other ideas that have been floated as well, but this is enough to start a wiki page for this discussion if warranted.
-Tim Cole
From: Robert Sanderson [mailto:azaroth42@gmail.com]
Sent: Monday, August 03, 2015 1:03 PM
To: Ivan Herman <ivan@w3.org>
Cc: Frederick Hirsch <w3c@fjhirsch.com>; Denenberg, Ray <rden@loc.gov>; W3C Public Annotation List <public-annotation@w3.org>
Subject: Re: [model] Clarifying annotation architecture
Sorry, yes that JSON is fine (after s/kind/@type/). It must be "source" (as per Frederick's example) not "@id" (as per my previous ones), which I missed.
So for an embedded comment with a role, it would look like:
{
"@type": "Annotation",
"target": "uri-for-target",
"body":
{
"role": "commenting",
"source":
{
"@type": "EmbeddedContent",
"chars": "Some Text here",
"format": "text/plain"
}
}
}
Rob
On Mon, Aug 3, 2015 at 4:01 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org> > wrote:
(Coming late in the discussion, having been on vacations)
> On 23 Jul 2015, at 17:34 , Frederick Hirsch <w3c@fjhirsch.com <mailto:w3c@fjhirsch.com> > wrote:
>
> (not as chair)
>
And not as a staff contact:-)
> Rob
>
> yes that helps quite a bit.
>
> I still see a problem explaining to JSON (non-turtle, non-RDF, non-JSON-LD) people why what looks like straightforward JSON is wrong, since they don't care about SpecificResources and triples..
>
> if there were no JSON-LD and no linked data, the following *would be fine* JSON, right?
>
> {
> "kind": "Annotation",
> "target" : "some-uri.html",
> "body": {
> "source: "meme-image.jpg",
> "role": "commenting"
> }
> }
>
Rob, why isn't this structure o.k.?
I have ran this through the JSON-LD playground (adding a prefix to the properties to avoid writing a separate context) and the result, in terms of N-Triples, is this:
_:b0 <o:body> _:b1 .
_:b0 <o:kind> "Annotation" .
_:b0 <o:target> "some-uri.html" .
_:b1 <o:role> "commenting" .
_:b1 <o:source> "meme-image.jpg" .
translated back into Turtle for readability:
_:b0
<o:kind> "Annotation",
<o:target> "some-uri.html",
<o:body> [
<o:role> "commenting",
<o:source> "meme-image.jpg"
] .
The only difference I can see is that there is no explicit typing for SpecificResource. So what? Only RDF people really care about the exact typing, and if we define the vocabulary in such a way that the domain of "source" is SpecificResource, then we got it.
What do I miss?
Ivan
> This is why the problem is "non-obvious".
>
> Is there a way to transform this via implementation to using SpecificResource by default? Did this come up in the JSON-LD discussions?
>
> Does this make the issue clear from the JSON implementer point of view?
>
> regards, Frederick
>
> Frederick Hirsch
>
> fjhirsch.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__fjhirsch.com&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=TLBR-u5pQghZ1Hq5MEEwbg3Sym7E5Sy3rNKQs6gto_4&s=bPuC1dt7Q6dewSTCnq3mVMZSNzMBHdDQaOnO8QO9yUk&e=>
> @fjhirsch
>
>
>> On Jul 23, 2015, at 11:02 AM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com> > wrote:
>>
>>
>> Sure!
>>
>> Good:
>>
>> _:anno a oa:Annotation ;
>> oa:hasTarget <some-uri.html> ;
>> oa:hasBody _:specres .
>>
>> _:specres a oa:SpecificResource ;
>> oa:motivatedBy oa:commenting ;
>> oa:hasSource <meme-image.jpg> .
>>
>>
>> Bad:
>>
>> _:anno a oa:Annotation ;
>> oa:hasTarget <some-uri.html> ;
>> oa:hasBody <meme-image.jpg> .
>>
>> <meme-image.jpg> oa:motivatedBy oa:commenting .
>>
>>
>> (Or substitute some new predicate like oa:role or whatever, per Tim Cole's comment that specific resources aren't really motivated in the same way that annotations are)
>>
>> Hope that helps :)
>>
>> Rob
>>
>>
>> On Thu, Jul 23, 2015 at 7:58 AM, Denenberg, Ray <rden@loc.gov <mailto:rden@loc.gov> > wrote:
>> Rob – still trying to grasp this. Could you show how this would look done the “right” way, I.e. as a specific resource,
>>
>>
>>
>> AND please write both (the bad example and the good) in turtle, not json-ld.
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Ray
>>
>>
>>
>>
>>
>> From: Robert Sanderson [mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com> ]
>> Sent: Thursday, July 23, 2015 10:30 AM
>> To: Denenberg, Ray
>> Cc: Jacob Jett; Frederick Hirsch; W3C Public Annotation List
>>
>>
>> Subject: Re: [model] Clarifying annotation architecture
>>
>>
>>
>>
>>
>> We shouldn't (must not) do this:
>>
>>
>>
>> {
>>
>> "@type": "Annotation",
>>
>> "target" : "some-uri.html",
>>
>> "body": {
>>
>> "@id": "meme-image.jpg",
>>
>> "role": "commenting"
>>
>> }
>>
>> }
>>
>>
>>
>> As meme-image.jpg might have another role in a different annotation (replacing, in Doug's example)
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>> On Thu, Jul 23, 2015 at 6:37 AM, Denenberg, Ray <rden@loc.gov <mailto:rden@loc.gov> > wrote:
>>
>> Hi Jacob – No, I’m afraid I don’t see that the “sky colored red” example applies to my question, however, if you (or someone) could write, in RDF syntax, an example annotation, which does specifically what it is we are saying we shouldn’t do … specifically: attach a motivation to a body (and more specifically, where the body is an image or some other non-rdf resource) ... that would help.
>>
>> Thanks.
>>
>>
>>
>> Ray
>>
>>
>>
>> From: jgjett@gmail.com <mailto:jgjett@gmail.com> [mailto:jgjett@gmail.com <mailto:jgjett@gmail.com> ] On Behalf Of Jacob Jett
>> Sent: Wednesday, July 22, 2015 5:16 PM
>> To: Denenberg, Ray
>> Cc: Robert Sanderson; Frederick Hirsch; W3C Public Annotation List
>>
>>
>> Subject: Re: [model] Clarifying annotation architecture
>>
>>
>>
>> Hi Ray,
>>
>>
>>
>> This is a distinctly RDF thing. Essentially the triples are all distinct assertions.
>>
>>
>>
>> Imagine that I told you, "the sky is red". In ttl we might write the assertion this way --
>>
>> Sky colored Red .
>>
>>
>>
>> This statement is true at certain points in time. Unfortunately RDF does not have a way to scope the assertion to certain points in time (or in the roles example, specific contexts). So from the SemWeb perspective "Sky colored Red ." and "Sky colored Blue ." are both true at all times and in all places. Using the specific resource allows us to scope the assertions, e.g., Sky@time@place colored Red .
>>
>>
>>
>> Is that example helpful at all?
>>
>>
>>
>> I think Rob's suggestion is a reasonable work around for this role issue. It should be invisible to those who don't care about SemWeb issues and makes the data reasonably actionable for those who do.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Jacob
>>
>>
>>
>>
>>
>> _____________________________________________________
>>
>> Jacob Jett
>> Research Assistant
>> Center for Informatics Research in Science and Scholarship
>> The Graduate School of Library and Information Science
>> University of Illinois at Urbana-Champaign
>> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
>> (217) 244-2164 <tel:%28217%29%20244-2164>
>> jjett2@illinois.edu <mailto:jjett2@illinois.edu>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 4:00 PM, Denenberg, Ray <rden@loc.gov <mailto:rden@loc.gov> > wrote:
>>
>> There is a fundamental piece of this that I’m missing.
>>
>> {
>>
>> "@type": "Annotation",
>>
>> "target": "some-uri.html",
>>
>> "body": {
>>
>> "@type": "SpecificResource",
>>
>> "motivation" : "editing",
>>
>> "source": "meme-image.jpg"
>>
>> }
>>
>>
>>
>> You create a new resource (specific resource) in order to associate a motivation (editing) with the original resource (source).
>>
>>
>>
>> And you do this to avoid “directly assigning a role to the original resource”.
>>
>>
>>
>> I understand the reason why. What I don’t understand is how it is proposed to do the latter in the first place. In the example, the original resource is an image. Not like it’s an RDF description that you can stick an RDF triple into.
>>
>>
>> What am I missing here?
>>
>>
>>
>> Ray
>>
>>
>>
>>
>>
>> From: Robert Sanderson [mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com> ]
>> Sent: Wednesday, July 22, 2015 2:45 PM
>> To: Frederick Hirsch
>> Cc: W3C Public Annotation List
>> Subject: Re: [model] Clarifying annotation architecture
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> * Associate the role with the body directly. Fails because it makes the body un-reusable, which for the image/video or similar case is not acceptable.
>>
>>
>>
>> This statement is a key issue and I think Doug was asking about this as well during the call.
>> The failure scenario is not clear. Un-resuable : re-used by whom and for what?
>>
>>
>>
>> Reused anywhere by anyone for anything, but most importantly reused as a body in a different annotation with a different role.
>>
>> As per Doug's example, you could not use the meme image as a comment in one annotation and a replacement in another annotation.
>>
>>
>>
>>
>>
>> If I forget the semantic web (for a moment) I can have an object, say a body, that has properties, including hasSegment or role and two bodies could have different values for the properties.
>>
>>
>>
>> Sure. If I forget that I need to close my tags and put quotes around my single token attributes, I end up with SGML ... but that sure isn't XML. Or if we conveniently forget about HTTP requirements, we could not worry about all those pesky headers. We could just stuff everything in the URL ... that would be much simpler, no? Then you would only ever need to do a GET, and could type it into your browser bar.
>>
>>
>>
>>
>>
>> The only re-use issue would be an implementation optimization (e.g. I don't want to duplicate an embedded image/video to save space)
>>
>> In semantic web terms:
>> annotation1 has body1.
>> annotation1 has body2.
>> body1 hasRole A.
>> body2 hasRole B.
>>
>>
>>
>> annotation2 has body1
>>
>> body1 hasRole B.
>>
>>
>>
>> Now body1 has both A and B roles.
>>
>>
>>
>>
>>
>> so where is the problem, and where is the re-use?
>>
>>
>>
>> There was no problem until someone else (annotation2) also assigned a different role to the body, and now it has both of them at once.
>>
>>
>>
>>
>>
>>> * Associate the role (motivation) with a specific resource. Works as expected without changing the semantics, breaking linked data, or introducing any new classes or properties.
>>
>> isn't a body a resource? If it isn't a resource, what is it?
>>
>>
>>
>> Well... the preferred answer would be yes, it's a resource. But it's also a literal string :P
>>
>> However snark aside, I'm not sure as to what's prompting the question?
>>
>>
>>
>> Perhaps to clarify the bullet: ... with a oa:SpecificResource.
>>
>>
>>
>> {
>>
>> "@type": "Annotation",
>>
>> "target": "some-uri.html",
>>
>> "body": {
>>
>> "@type": "SpecificResource",
>>
>> "motivation" : "editing",
>>
>> "source": "meme-image.jpg"
>>
>> }
>>
>> }
>>
>>
>>
>> R
>>
>>
>>
>>
>>
>> --
>>
>> 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
>>
>>
>>
>>
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
>
>
>
>
>
>
----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_People_Ivan_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=TLBR-u5pQghZ1Hq5MEEwbg3Sym7E5Sy3rNKQs6gto_4&s=GRiEC61n2yS3VDQBz7yOednnE3jLkAxkKF3alucUquE&e=>
mobile: +31-641044153 <tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704 <https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_0000-2D0003-2D0782-2D2704&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=TLBR-u5pQghZ1Hq5MEEwbg3Sym7E5Sy3rNKQs6gto_4&s=4qhcRgfgc5_mE7mB6Uid64rmzUFaBCRtoCaYgZ2VWYQ&e=>
--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305
Received on Monday, 3 August 2015 20:46:57 UTC