linked data notification example

106 views
Skip to first unread message

Jeffrey C. Witt

unread,
Nov 20, 2016, 7:27:40 PM11/20/16
to IIIF Discuss
I know planning for the Vatican in June is probably just getting started, but I want to put a vote in for a panel on "social web notifications" with working demos of "webmentions", "linked data notifications", and possibly a "pub-sub" approach, so that all three approaches could be evaluated in subsequent working groups. 

This weekend, at a very exciting meeting at Penn, I met another large project based at Princeton with an extremely similar use case to my own (this is the Princeton Geniza Lab: https://www.princeton.edu/~geniza/). They have lots of quality metadata (transcriptions, translations, etc.) for images, scattered and hosted by other libraries, including the Penn Library. The SCTA also has metadata and transcriptions about manuscripts at Penn. So this spring, I'd like to build another set of demos involving multiple research groups (the SCTA and the Princeton Geniza Lab) and multiple libraries (Penn, hopefully also with Harvard, and e-codices). This weekend we began planning for a small meeting at Penn with the Geniza lab to try to realize a more elaborate demo before the Vatican meeting. But this time I'd like to implement it with the Linked Data Notification spec, so that we could compare this demo with the webmention and analyze the pros and cons. (Note: this only takes care of two approaches, if we want the pub-sub approach to be a contender, we need to find a way to get a demo of that as well. Anyone??)

Along these lines, I've started sketching out how I would re-implement the webmention demo (seen here: http://lombardpress.org/2016/04/16/iiif-webmentions/). In general, both approaches seem pretty similar, but I've tried to re-write the relevant requests and responses following the working w3c spec (https://www.w3.org/TR/ldn/)

Target's Response -- IIIF Manifest (requires "inbox" property on manifest object):

HEAD /metadata/iiif/kba-WettF0015/manifest.json HTTP/1.1
Accept: application/ld+json

HTTP/1.1 200 OK


{
  ... rest of manifest
}

Sender's Post

POST /ldn/inbox/ HTTP/1.1
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

Sender's Announcement

{
  "@id": "",
  "@type": "Announce",
  "actor": "http://scta.info",
  "updated": "2016-06-28T19:56:20.114Z"
}

Sender's Object

The supplement object with the "supplement" wrapper is probably the most controversial part of the earlier webmention demo. I also wish that this wrapper could be jettisoned, and I think in the case of a search service and a layer they could.  In most cases, the above "announcement" basically replaces the "supplement" wrapper we proposed earlier. 

However, I still have a problem with ranges. Because IIIF doesn't have a concept of a RangeList (i.e. a single object for the entire set of ranges), I can't point to the entire set of ranges in the Linked Data Announcement with one de-referencable URL. Thus the supplement becomes a wrapper, and the "profile" is a way to say the announcement is a connect grouping of ranges. With such a wrapper, I fear I would have to send a separate announcement range with the proposed range list.

(any chance IIIF would ever support a "RangeList" object, analogous to an "AnnotationList"?)


{
  "@type": "supplement",
  "within": [
  ],
  "attribution": "Data provided by the Scholastic Commentaries and Texts Archive",
  "description": "A range list for Sentences Commentary rothwellcommentary/wettf15",
  "ranges": [
    {
      "@type": "sc:Range",
      "label": "William de Rothwell Commentary",
      "viewingHint": "top",
      "ranges": [
        ]
    },
  ]
}


Inbox Post Response

POST /ldn/inbox/ HTTP/1.1
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@type": "Announce",
  "actor": "http://scta.info",
  "updated": "2016-06-28T19:56:20.114Z"
}

HTTP/1.1 201 Created

Inbox Get Response for notifications 9272f00

(Again, the object value for the "object" key could be, the entire layer, search service, or a RangeList (if there were such a thing), but for now it's just the supplement object.)

GET /ldn/inbox/9272f00 HTTP/1.1
Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6

HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": [
    { "@language": "en" }
  ],
  "@type": "Announce",
  "object": {
    "@type": "supplement",
    "within": [
    ],
    "attribution": "Data provided by the Scholastic Commentaries and Texts Archive",
    "description": "A range list for Sentences Commentary rothwellcommentary/wettf15",
    "logo": "http://scta.info/logo.png",
    "ranges": [
      {
        "@type": "sc:Range",
        "label": "William de Rothwell Commentary",
        "viewingHint": "top",
        "ranges": [
          ]
      },
   ]
  },
  "updated": {
    "@value": "2016-06-28T19:56:20.114Z"
  }
}

There may be places where I'm WAY of track, so comments and corrections are most welcome.

Jeffrey C. Witt

unread,
Nov 22, 2016, 11:06:25 AM11/22/16
to IIIF Discuss
Follow up: I built a little rails app today to function as a generic linked data notification "inbox". Below are set of screen shots that basically illustrate the sequence of sending a notification to a discovered ldp inbox.

Example post body

Example Curl sending of Post


Rails rendering of ldp inbox



I could also filter the above list, so that it shows all notifications for a specific manifest (when the manifest is given as a parameter)


Rails json output of requesting a particular notification





I suppose the idea is that anyone interested in a particular manifest can check the "inbox" for existing notifications, and can then inspect the "object" for each notification and then decide if they would like to bring that object into their re-construction of their manifest or even into an entirely different system.


Thoughts welcome.


jw

Robert Sanderson

unread,
Nov 22, 2016, 4:16:13 PM11/22/16
to iiif-d...@googlegroups.com


Hi Jeff,

Thanks for this work :) It's really great to have actual implementations demonstrating what can be done ahead of the specifications, so we come at it armed with knowledge and practical experience, rather than just an armload of intersecting specifications from around the web.

I think one of the advantages of the LDN approach is that the payload can be modified suit our community's needs, rather than being stuck with just target and source in WebMention. [Or risk extension collision with other communities]  Given this, there seems to be three new approaches available to us:

1.  In your example, you could repeat the object property in the Announcement to avoid creating temporary supplements:

{
  "@id": "",
  "@type": "Announce",
  "actor": "http://scta.info",
  "object": [
  "updated": "2016-06-28T19:56:20.114Z"
}

This would solve the multiple notification issue where each new resource from the sender needs its own notification.
The cost (of course) is that the sender would need to ensure those resources would resolve ... but that would be good practice regardless, in a distributed system.

2.  Instead of the AS2 announce pattern, we could use something custom that looked more like your supplement.  This would let the notification carry the attribution, license and so forth rather than requiring a separate non-standard resource.

3.  Ranges can live within ranges ... So the ToC range seems like a reasonable single resource to notify the target resource about.  For example you could change the type to Range and it would be a conforming Range, I believe :)  So combined with 1, you could have the top level range and any other resources you wanted to create a notification about merged into one.

Hope that helps!

Rob


--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

Jeffrey C. Witt

unread,
Nov 23, 2016, 9:53:34 AM11/23/16
to iiif-d...@googlegroups.com
Hmm, ok. 

Tell me what you think of the following three links as potential notifications

Example 1

This is what I see as the simplest case. It is the announcement of an available layer. The wrapper is very simple. There is an "id" for the sender's notification, and "updated" property to announce the last time the notification was changed, a "source" to indicate the domain from which the announcement comes, a "target" (i.e. the manifest that should include and "inbox" property), and then the "object". 

The "object" can either be a dereferencable link to an json object, an array of dereferencable links, a json object itself, or an array of json objects. In this case it is a dereferencable link. Clients requesting the notification from the inbox will have to dereference the link, from here they need to look for the @type property in order to know what kind of "supplemental" data this. Based on this @type, they should know how to incorporate it into a manifest or their custom system.

"Attribution" and "license" information could be added to the Announcement itself, but I think this information is more pertinent to the object of the announcement and should be gleaned from object properties. See range example below.


This example is fairly similar except, the object doesn't point to a de-referencable link, but provides the json object itself. There are no examples of a "@type": "service" in the IIIF search api, but I added it here because I'm expecting the client should be using the @type property to know what kind of information is being announced and what to do with it. (But this competes with an example I saw, where the value of "type" in service block was "feature" see http://iiif.io/api/annex/services/#geojson). Something else besides "type" could be used, I guess. However, on this approach, it would have to be the same property on all announced objects.

Once the client knows that it is a "service" and not a "layer" or "range" it can check the service "profile" to know what kind service it is and whether or not they want to incorporate it. 


Here's the range announcement. The "object" property is taking a single object that then wraps a flat list of all other connected ranges being announced. The @type can be used to recognize this as a range. The viewing hint is set to "wrapper" to alert the client that this is a wrapper and should be discarded. Using a "wrapper" range like this also allows me to create a dereferencable id for the entire set of ranges (e.g. http://scta.info/iiif/rothwellcommentary/wettf15/ranges/toc/wrapper). Such a dereferencable collection of ranges would also allow me to just provide the link as the value of the "object". Further, if I had several different ranges for this manifest, I could send them to e-codices all at once, as an array of dereferencable links to range wrappers.

Let me know what you think. (But make sure to respond only at your leisure. It's Thanksgiving break after all!)

Happy Turkey week. 

jw


You received this message because you are subscribed to a topic in the Google Groups "IIIF Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/iiif-discuss/DMGdfHcfH8o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to iiif-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Dr. Jeffrey C. Witt
Philosophy Department
Loyola University Maryland
4501 N. Charles St.
Baltimore, MD 21210
Reply all
Reply to author
Forward
0 new messages