Creating an "index" of photos and referencing from multiple files

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating an "index" of photos and referencing from multiple files

Aris Karatarakis-2
Dear all,

would like some feedback on the following:

I’ve been trying to figure out a method that allows referencing the same photos from multiple files without having to repeat the figure element and all other encoded information. 

An example case  would be to re-use photos of  persons mentioned in different text or section of a project (or even different projects).

After re-reading  section 16 Linking, Segmentation, and Alignment from the Guidelines and one of my initial scenarios would be: 

- create a  folder titled "media_photos" containing all the images

- create a file titled "index_photos.xml" which is essentially a big list of "figure" elements containing references to the photos within the "media_photos" folder and some additional info such as captions, copyrights, descriptions. This would be the file that all other files would "target"

- from another file e.g.  "somefile.xml" create a "prefixDef" with @ident attribute value set to e.g. "img"

somewhere within the "somefile.xml" (let's say within a paragraph) an image would be referenced using e.g. a "ptr"  element with @target attribute value set to "img:someImage.png" 
 
I would be grateful for any suggestions/corrections or links to existing projects following a similar approach.

Best, Aris

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Syd Bauman-9
Would using XInclude suffice for your purpose?

--------- excerpt of index_photos.xml ---------

        <figure xml:id="F03">
          <figDesc>blah blah ...</figDesc>
          <graphic url="../media_photos/f03.jpg"/>
          <ab type="caption">blah blah ...</ab>
        </figure>

--------- excerpt of somefile.xml ---------

        <xi:include href="./index_photos.xml" xpointer="element(F03)">
          <xi:fallback><p>Unable to find F03!</p></xi:fallback>
        </xi:include>

On a quick read the plan you sketched out sounds fine. The one
missing bit that jumps to mind is the semantics of the <ptr>. If you
have no other <ptr> elements, you can get away with just assuming the
semantics of <ptr> are "go get that thing and insert it here". But
often you want <ptr>s for other reasons, too. So it might be better
to put a @type on these <ptr>s to make this "inclusion" semantic
clear.

> would like some feedback on the following:
>
> I’ve been trying to figure out a method that allows referencing the same
> photos from multiple files without having to repeat the figure element and
> all other encoded information.
>
> An example case  would be to re-use photos of  persons mentioned in
> different text or section of a project (or even different projects).
>
> After re-reading  section 16 Linking, Segmentation, and Alignment from the
> Guidelines and one of my initial scenarios would be:
>
> - create a  folder titled "media_photos" containing all the images
>
> - create a file titled "index_photos.xml" which is essentially a big list
> of "figure" elements containing references to the photos within the
> "media_photos" folder and some additional info such as captions,
> copyrights, descriptions. This would be the file that all other files would
> "target"
>
> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
> attribute value set to e.g. "img"
>
> somewhere within the "somefile.xml" (let's say within a paragraph) an image
> would be referenced using e.g. a "ptr"  element with @target attribute
> value set to "img:someImage.png"
>
> I would be grateful for any suggestions/corrections or links to existing
> projects following a similar approach.
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Stuart A. Yeates
The NZETC does this with glyph / g, but that's many meant for character level things. Not sure if your images are at that level.

cheers
stuart

--
...let us be heard from red core to black sky

On Sun, Mar 13, 2016 at 9:18 AM, Syd Bauman <[hidden email]> wrote:
Would using XInclude suffice for your purpose?

--------- excerpt of index_photos.xml ---------

        <figure xml:id="F03">
          <figDesc>blah blah ...</figDesc>
          <graphic url="../media_photos/f03.jpg"/>
          <ab type="caption">blah blah ...</ab>
        </figure>

--------- excerpt of somefile.xml ---------

        <xi:include href="./index_photos.xml" xpointer="element(F03)">
          <xi:fallback><p>Unable to find F03!</p></xi:fallback>
        </xi:include>

On a quick read the plan you sketched out sounds fine. The one
missing bit that jumps to mind is the semantics of the <ptr>. If you
have no other <ptr> elements, you can get away with just assuming the
semantics of <ptr> are "go get that thing and insert it here". But
often you want <ptr>s for other reasons, too. So it might be better
to put a @type on these <ptr>s to make this "inclusion" semantic
clear.

> would like some feedback on the following:
>
> I’ve been trying to figure out a method that allows referencing the same
> photos from multiple files without having to repeat the figure element and
> all other encoded information.
>
> An example case  would be to re-use photos of  persons mentioned in
> different text or section of a project (or even different projects).
>
> After re-reading  section 16 Linking, Segmentation, and Alignment from the
> Guidelines and one of my initial scenarios would be:
>
> - create a  folder titled "media_photos" containing all the images
>
> - create a file titled "index_photos.xml" which is essentially a big list
> of "figure" elements containing references to the photos within the
> "media_photos" folder and some additional info such as captions,
> copyrights, descriptions. This would be the file that all other files would
> "target"
>
> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
> attribute value set to e.g. "img"
>
> somewhere within the "somefile.xml" (let's say within a paragraph) an image
> would be referenced using e.g. a "ptr"  element with @target attribute
> value set to "img:someImage.png"
>
> I would be grateful for any suggestions/corrections or links to existing
> projects following a similar approach.

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Martin Holmes
In reply to this post by Syd Bauman-9
Any particular reason for choosing <ptr> over <graphic
url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?

Cheers,
Martin

On 16-03-12 12:18 PM, Syd Bauman wrote:

> Would using XInclude suffice for your purpose?
>
> --------- excerpt of index_photos.xml ---------
>
>          <figure xml:id="F03">
>            <figDesc>blah blah ...</figDesc>
>            <graphic url="../media_photos/f03.jpg"/>
>            <ab type="caption">blah blah ...</ab>
>          </figure>
>
> --------- excerpt of somefile.xml ---------
>
>          <xi:include href="./index_photos.xml" xpointer="element(F03)">
>            <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>          </xi:include>
>
> On a quick read the plan you sketched out sounds fine. The one
> missing bit that jumps to mind is the semantics of the <ptr>. If you
> have no other <ptr> elements, you can get away with just assuming the
> semantics of <ptr> are "go get that thing and insert it here". But
> often you want <ptr>s for other reasons, too. So it might be better
> to put a @type on these <ptr>s to make this "inclusion" semantic
> clear.
>
>> would like some feedback on the following:
>>
>> I’ve been trying to figure out a method that allows referencing the same
>> photos from multiple files without having to repeat the figure element and
>> all other encoded information.
>>
>> An example case  would be to re-use photos of  persons mentioned in
>> different text or section of a project (or even different projects).
>>
>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>> Guidelines and one of my initial scenarios would be:
>>
>> - create a  folder titled "media_photos" containing all the images
>>
>> - create a file titled "index_photos.xml" which is essentially a big list
>> of "figure" elements containing references to the photos within the
>> "media_photos" folder and some additional info such as captions,
>> copyrights, descriptions. This would be the file that all other files would
>> "target"
>>
>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>> attribute value set to e.g. "img"
>>
>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>> would be referenced using e.g. a "ptr"  element with @target attribute
>> value set to "img:someImage.png"
>>
>> I would be grateful for any suggestions/corrections or links to existing
>> projects following a similar approach.
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Robinson, Peter
Look at iiif.io. I suspect shared canvas gives you all you want
Peter

> On Mar 12, 2016, at 3:47 PM, Martin Holmes <[hidden email]> wrote:
>
> Any particular reason for choosing <ptr> over <graphic url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?
>
> Cheers,
> Martin
>
> On 16-03-12 12:18 PM, Syd Bauman wrote:
>> Would using XInclude suffice for your purpose?
>>
>> --------- excerpt of index_photos.xml ---------
>>
>>         <figure xml:id="F03">
>>           <figDesc>blah blah ...</figDesc>
>>           <graphic url="../media_photos/f03.jpg"/>
>>           <ab type="caption">blah blah ...</ab>
>>         </figure>
>>
>> --------- excerpt of somefile.xml ---------
>>
>>         <xi:include href="./index_photos.xml" xpointer="element(F03)">
>>           <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>>         </xi:include>
>>
>> On a quick read the plan you sketched out sounds fine. The one
>> missing bit that jumps to mind is the semantics of the <ptr>. If you
>> have no other <ptr> elements, you can get away with just assuming the
>> semantics of <ptr> are "go get that thing and insert it here". But
>> often you want <ptr>s for other reasons, too. So it might be better
>> to put a @type on these <ptr>s to make this "inclusion" semantic
>> clear.
>>
>>> would like some feedback on the following:
>>>
>>> I’ve been trying to figure out a method that allows referencing the same
>>> photos from multiple files without having to repeat the figure element and
>>> all other encoded information.
>>>
>>> An example case  would be to re-use photos of  persons mentioned in
>>> different text or section of a project (or even different projects).
>>>
>>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>>> Guidelines and one of my initial scenarios would be:
>>>
>>> - create a  folder titled "media_photos" containing all the images
>>>
>>> - create a file titled "index_photos.xml" which is essentially a big list
>>> of "figure" elements containing references to the photos within the
>>> "media_photos" folder and some additional info such as captions,
>>> copyrights, descriptions. This would be the file that all other files would
>>> "target"
>>>
>>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>>> attribute value set to e.g. "img"
>>>
>>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>>> would be referenced using e.g. a "ptr"  element with @target attribute
>>> value set to "img:someImage.png"
>>>
>>> I would be grateful for any suggestions/corrections or links to existing
>>> projects following a similar approach.

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Martin Holmes
On 16-03-12 04:35 PM, Robinson, Peter wrote:
> Look at iiif.io. I suspect shared canvas gives you all you want

<quote>

  The basic steps to getting started with IIIF are:

      - Deploy an image server that supports the IIIF Image API

      - Publish metadata about your image-based objects that complies to
IIIF Presentation API

      - Deploy and integrate software that allows you to discover and
display IIIF-compliant image resources

</quote>
<ref target="http://iiif.io/technical-details/">IIIF site</ref>

That's a bit much when all you want to do is link to some local images
in an efficient way, surely?

Cheers,
Martin

> Peter
>> On Mar 12, 2016, at 3:47 PM, Martin Holmes <[hidden email]> wrote:
>>
>> Any particular reason for choosing <ptr> over <graphic url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?
>>
>> Cheers,
>> Martin
>>
>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>> Would using XInclude suffice for your purpose?
>>>
>>> --------- excerpt of index_photos.xml ---------
>>>
>>>          <figure xml:id="F03">
>>>            <figDesc>blah blah ...</figDesc>
>>>            <graphic url="../media_photos/f03.jpg"/>
>>>            <ab type="caption">blah blah ...</ab>
>>>          </figure>
>>>
>>> --------- excerpt of somefile.xml ---------
>>>
>>>          <xi:include href="./index_photos.xml" xpointer="element(F03)">
>>>            <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>>>          </xi:include>
>>>
>>> On a quick read the plan you sketched out sounds fine. The one
>>> missing bit that jumps to mind is the semantics of the <ptr>. If you
>>> have no other <ptr> elements, you can get away with just assuming the
>>> semantics of <ptr> are "go get that thing and insert it here". But
>>> often you want <ptr>s for other reasons, too. So it might be better
>>> to put a @type on these <ptr>s to make this "inclusion" semantic
>>> clear.
>>>
>>>> would like some feedback on the following:
>>>>
>>>> I’ve been trying to figure out a method that allows referencing the same
>>>> photos from multiple files without having to repeat the figure element and
>>>> all other encoded information.
>>>>
>>>> An example case  would be to re-use photos of  persons mentioned in
>>>> different text or section of a project (or even different projects).
>>>>
>>>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>>>> Guidelines and one of my initial scenarios would be:
>>>>
>>>> - create a  folder titled "media_photos" containing all the images
>>>>
>>>> - create a file titled "index_photos.xml" which is essentially a big list
>>>> of "figure" elements containing references to the photos within the
>>>> "media_photos" folder and some additional info such as captions,
>>>> copyrights, descriptions. This would be the file that all other files would
>>>> "target"
>>>>
>>>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>>>> attribute value set to e.g. "img"
>>>>
>>>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>>>> would be referenced using e.g. a "ptr"  element with @target attribute
>>>> value set to "img:someImage.png"
>>>>
>>>> I would be grateful for any suggestions/corrections or links to existing
>>>> projects following a similar approach.
>
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

David Maus
In reply to this post by Aris Karatarakis-2
Hi,

On Sat, 12 Mar 2016 20:47:22 +0100,
Aris Karatarakis wrote:

>
> [1  <text/plain; UTF-8 (quoted-printable)>]
> [2  <text/html; UTF-8 (quoted-printable)>]
> Dear all,
>
> would like some feedback on the following:
>
> I’ve been trying to figure out a method that allows referencing the
> same photos from multiple files without having to repeat the figure
> element and all other encoded information.
>
> ...
>
> - create a folder titled "media_photos" containing all the images
>
> - create a file titled "index_photos.xml" which is essentially a big
> list of "figure" elements containing references to the photos within
> the "media_photos" folder and some additional info such as captions,
> copyrights, descriptions. This would be the file that all other files
> would "target"
>
> - from another file e.g. "somefile.xml" create a "prefixDef" with
> @ident attribute value set to e.g. "img"
>
> somewhere within the "somefile.xml" (let's say within a paragraph) an
> image would be referenced using e.g. a "ptr" element with @target
> attribute value set to "img:someImage.png"

If you want to reference the <figure> you could give each <figure> a
@xml:id and reference the <figure> in a <ptr>:

,----[ media_photos/index_photos.xml ]---
| <figure xml:id="fig03">
|   …
| </figure>
`----

,----[ somefile.xml ]--
| <ptr target="media_photos/index_photos.xml#fig03"/>
`----

HTH,
  -- David

> I would be grateful for any suggestions/corrections or links to
> existing projects following a similar approach.
>
> Best, Aris
>

--
David Maus
Herzog August Bibliothek - D-38299 Wolfenbuettel
Bibliothekarische IT / Digital Humanities
Phone: +49-5331-808-317
Email: [hidden email]

PGP Key 0x27023DFCE78FF66C
Fingerprint 6F78 76BD 2008 94F4 D8C4  6BB3 2702 3DFC E78F F66C
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Aris Karatarakis-2
In reply to this post by Aris Karatarakis-2
Dear all,

thank you all for your suggestions

- no specific reason for choosing <ptr> element it was just an example, as mentioned @type would be used to clarify its usage
- I avoided XInclude as in earlier versions of oXygen I experienced some slow down (haven’t tested it with the latest version)
- iiif.io sounds very interesting, I will have a detailed look at it and perhaps use it at a later stage

Best

Aris
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Robinson, Peter
In reply to this post by Martin Holmes
Couple of points…
1. using IIIF.IO makes the images available through many different online viewers
2. the viewers, images and servers are optimized for web delivery
etc
I guess if all you want is local delivery, then iiif would be overkill.  But then, so is XML/TEI.  Why not good old html?
Oh dear, now I went and said it.
p

> On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]> wrote:
>
> On 16-03-12 04:35 PM, Robinson, Peter wrote:
>> Look at iiif.io. I suspect shared canvas gives you all you want
>
> <quote>
>
> The basic steps to getting started with IIIF are:
>
>     - Deploy an image server that supports the IIIF Image API
>
>     - Publish metadata about your image-based objects that complies to IIIF Presentation API
>
>     - Deploy and integrate software that allows you to discover and display IIIF-compliant image resources
>
> </quote>
> <ref target="http://iiif.io/technical-details/">IIIF site</ref>
>
> That's a bit much when all you want to do is link to some local images in an efficient way, surely?
>
> Cheers,
> Martin
>
>> Peter
>>> On Mar 12, 2016, at 3:47 PM, Martin Holmes <[hidden email]> wrote:
>>>
>>> Any particular reason for choosing <ptr> over <graphic url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>>> Would using XInclude suffice for your purpose?
>>>>
>>>> --------- excerpt of index_photos.xml ---------
>>>>
>>>>         <figure xml:id="F03">
>>>>           <figDesc>blah blah ...</figDesc>
>>>>           <graphic url="../media_photos/f03.jpg"/>
>>>>           <ab type="caption">blah blah ...</ab>
>>>>         </figure>
>>>>
>>>> --------- excerpt of somefile.xml ---------
>>>>
>>>>         <xi:include href="./index_photos.xml" xpointer="element(F03)">
>>>>           <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>>>>         </xi:include>
>>>>
>>>> On a quick read the plan you sketched out sounds fine. The one
>>>> missing bit that jumps to mind is the semantics of the <ptr>. If you
>>>> have no other <ptr> elements, you can get away with just assuming the
>>>> semantics of <ptr> are "go get that thing and insert it here". But
>>>> often you want <ptr>s for other reasons, too. So it might be better
>>>> to put a @type on these <ptr>s to make this "inclusion" semantic
>>>> clear.
>>>>
>>>>> would like some feedback on the following:
>>>>>
>>>>> I’ve been trying to figure out a method that allows referencing the same
>>>>> photos from multiple files without having to repeat the figure element and
>>>>> all other encoded information.
>>>>>
>>>>> An example case  would be to re-use photos of  persons mentioned in
>>>>> different text or section of a project (or even different projects).
>>>>>
>>>>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>>>>> Guidelines and one of my initial scenarios would be:
>>>>>
>>>>> - create a  folder titled "media_photos" containing all the images
>>>>>
>>>>> - create a file titled "index_photos.xml" which is essentially a big list
>>>>> of "figure" elements containing references to the photos within the
>>>>> "media_photos" folder and some additional info such as captions,
>>>>> copyrights, descriptions. This would be the file that all other files would
>>>>> "target"
>>>>>
>>>>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>>>>> attribute value set to e.g. "img"
>>>>>
>>>>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>>>>> would be referenced using e.g. a "ptr"  element with @target attribute
>>>>> value set to "img:someImage.png"
>>>>>
>>>>> I would be grateful for any suggestions/corrections or links to existing
>>>>> projects following a similar approach.
>>

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Martin Holmes
Hi Peter,

If you're creating a website, and you have enough images of a large
enough scale to justify IIIF, then it makes sense. But I think this was
just a question about TEI encoding.

 > I guess if all you want is local delivery, then iiif would be
 > overkill.  But then, so is XML/TEI.  Why not good old html?

Well, I use TEI for scholarly encoding, and HTML for delivering an
output from that encoding to an HTML user-agent. I presume you're not
seriously suggesting that we do all our scholarly encoding in HTML, are
you? If so, the answer is that:

a) It's not nuanced and rich enough;

b) If you make it so by the use of e.g. custom data- attributes and
custom elements, you're just replicating in an idiosyncratic and
non-interoperable form the work of the TEI community.

Cheers,
Martin



On 16-03-13 09:36 AM, Robinson, Peter wrote:

> Couple of points…
> 1. using IIIF.IO makes the images available through many different online viewers
> 2. the viewers, images and servers are optimized for web delivery
> etc
> I guess if all you want is local delivery, then iiif would be overkill.  But then, so is XML/TEI.  Why not good old html?
> Oh dear, now I went and said it.
> p
>> On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]> wrote:
>>
>> On 16-03-12 04:35 PM, Robinson, Peter wrote:
>>> Look at iiif.io. I suspect shared canvas gives you all you want
>>
>> <quote>
>>
>> The basic steps to getting started with IIIF are:
>>
>>      - Deploy an image server that supports the IIIF Image API
>>
>>      - Publish metadata about your image-based objects that complies to IIIF Presentation API
>>
>>      - Deploy and integrate software that allows you to discover and display IIIF-compliant image resources
>>
>> </quote>
>> <ref target="http://iiif.io/technical-details/">IIIF site</ref>
>>
>> That's a bit much when all you want to do is link to some local images in an efficient way, surely?
>>
>> Cheers,
>> Martin
>>
>>> Peter
>>>> On Mar 12, 2016, at 3:47 PM, Martin Holmes <[hidden email]> wrote:
>>>>
>>>> Any particular reason for choosing <ptr> over <graphic url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>>>> Would using XInclude suffice for your purpose?
>>>>>
>>>>> --------- excerpt of index_photos.xml ---------
>>>>>
>>>>>          <figure xml:id="F03">
>>>>>            <figDesc>blah blah ...</figDesc>
>>>>>            <graphic url="../media_photos/f03.jpg"/>
>>>>>            <ab type="caption">blah blah ...</ab>
>>>>>          </figure>
>>>>>
>>>>> --------- excerpt of somefile.xml ---------
>>>>>
>>>>>          <xi:include href="./index_photos.xml" xpointer="element(F03)">
>>>>>            <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>>>>>          </xi:include>
>>>>>
>>>>> On a quick read the plan you sketched out sounds fine. The one
>>>>> missing bit that jumps to mind is the semantics of the <ptr>. If you
>>>>> have no other <ptr> elements, you can get away with just assuming the
>>>>> semantics of <ptr> are "go get that thing and insert it here". But
>>>>> often you want <ptr>s for other reasons, too. So it might be better
>>>>> to put a @type on these <ptr>s to make this "inclusion" semantic
>>>>> clear.
>>>>>
>>>>>> would like some feedback on the following:
>>>>>>
>>>>>> I’ve been trying to figure out a method that allows referencing the same
>>>>>> photos from multiple files without having to repeat the figure element and
>>>>>> all other encoded information.
>>>>>>
>>>>>> An example case  would be to re-use photos of  persons mentioned in
>>>>>> different text or section of a project (or even different projects).
>>>>>>
>>>>>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>>>>>> Guidelines and one of my initial scenarios would be:
>>>>>>
>>>>>> - create a  folder titled "media_photos" containing all the images
>>>>>>
>>>>>> - create a file titled "index_photos.xml" which is essentially a big list
>>>>>> of "figure" elements containing references to the photos within the
>>>>>> "media_photos" folder and some additional info such as captions,
>>>>>> copyrights, descriptions. This would be the file that all other files would
>>>>>> "target"
>>>>>>
>>>>>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>>>>>> attribute value set to e.g. "img"
>>>>>>
>>>>>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>>>>>> would be referenced using e.g. a "ptr"  element with @target attribute
>>>>>> value set to "img:someImage.png"
>>>>>>
>>>>>> I would be grateful for any suggestions/corrections or links to existing
>>>>>> projects following a similar approach.
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Robinson, Peter
Hi Martin
I’ll admit to a hidden motive in my posting. IIIF is becoming a really significant player in the world of images and manuscripts. It is starting from multiple opposite ends from the TEI. IIIF begins with images and manuscripts.  It is intimately implementation-led. It uses JSON. The TEI begins with texts. It is implementation blind. It uses XML. However, the two worlds are moving towards each other. IIIF is looking at how better to handle the text of the documents it images. TEI (as your post shows) is exploring means of referencing quantities of images. There is already overlap between the two domains. I think there is a great deal of important work to be done in getting these two areas to work  together.  Both do some things really well which the other does not.  They are (and should be) complementary rather than opposed. So if this post alerts people in the TEI community to what is happening in IIIF, great.

I’m also influenced by recent work in the textual communities project, where we decided to alter all our image handling from a TEI/XML base to IIIF (as part of our mass move to JSON as our fundamental document store — but retaining TEI for multiple critical operations). This has been more than enough to persuade us that a partnership of IIIF and TEI is really productive.
Finally: if moving your images into IIIF is overkill when "all you want to do is link to some local images in an efficient way”, why is TEI/XML not also overkill? Yes, you need to install an IIIF server. But you need a server anyway. Of course, you can use vanilla apache — but the advantages of the IIIF server, optimized for handling tiled and scaled images, are really substantial.
A humble suggestion. For sure, for some parts of this, TEI encoding will make sense. For other parts, IIIF (shared canvas) will make the best sense. Be kind of neat to use this instance to show how the two can work together.
Just a suggestion.
Peter


> On Mar 13, 2016, at 3:06 PM, Martin Holmes <[hidden email]> wrote:
>
> Hi Peter,
>
> If you're creating a website, and you have enough images of a large
> enough scale to justify IIIF, then it makes sense. But I think this was
> just a question about TEI encoding.
>
> > I guess if all you want is local delivery, then iiif would be
> > overkill.  But then, so is XML/TEI.  Why not good old html?
>
> Well, I use TEI for scholarly encoding, and HTML for delivering an output from that encoding to an HTML user-agent. I presume you're not seriously suggesting that we do all our scholarly encoding in HTML, are you? If so, the answer is that:
>
> a) It's not nuanced and rich enough;
>
> b) If you make it so by the use of e.g. custom data- attributes and custom elements, you're just replicating in an idiosyncratic and non-interoperable form the work of the TEI community.
>
> Cheers,
> Martin
>
>
>
> On 16-03-13 09:36 AM, Robinson, Peter wrote:
>> Couple of points…
>> 1. using IIIF.IO makes the images available through many different online viewers
>> 2. the viewers, images and servers are optimized for web delivery
>> etc
>> I guess if all you want is local delivery, then iiif would be overkill.  But then, so is XML/TEI.  Why not good old html?
>> Oh dear, now I went and said it.
>> p
>>> On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]> wrote:
>>>
>>> On 16-03-12 04:35 PM, Robinson, Peter wrote:
>>>> Look at iiif.io. I suspect shared canvas gives you all you want
>>>
>>> <quote>
>>>
>>> The basic steps to getting started with IIIF are:
>>>
>>>     - Deploy an image server that supports the IIIF Image API
>>>
>>>     - Publish metadata about your image-based objects that complies to IIIF Presentation API
>>>
>>>     - Deploy and integrate software that allows you to discover and display IIIF-compliant image resources
>>>
>>> </quote>
>>> <ref target="http://iiif.io/technical-details/">IIIF site</ref>
>>>
>>> That's a bit much when all you want to do is link to some local images in an efficient way, surely?
>>>
>>> Cheers,
>>> Martin
>>>
>>>> Peter
>>>>> On Mar 12, 2016, at 3:47 PM, Martin Holmes <[hidden email]> wrote:
>>>>>
>>>>> Any particular reason for choosing <ptr> over <graphic url="img:someimage.png"/>? I think <graphic> makes more sense, doesn't it?
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>>>>> Would using XInclude suffice for your purpose?
>>>>>>
>>>>>> --------- excerpt of index_photos.xml ---------
>>>>>>
>>>>>>         <figure xml:id="F03">
>>>>>>           <figDesc>blah blah ...</figDesc>
>>>>>>           <graphic url="../media_photos/f03.jpg"/>
>>>>>>           <ab type="caption">blah blah ...</ab>
>>>>>>         </figure>
>>>>>>
>>>>>> --------- excerpt of somefile.xml ---------
>>>>>>
>>>>>>         <xi:include href="./index_photos.xml" xpointer="element(F03)">
>>>>>>           <xi:fallback><p>Unable to find F03!</p></xi:fallback>
>>>>>>         </xi:include>
>>>>>>
>>>>>> On a quick read the plan you sketched out sounds fine. The one
>>>>>> missing bit that jumps to mind is the semantics of the <ptr>. If you
>>>>>> have no other <ptr> elements, you can get away with just assuming the
>>>>>> semantics of <ptr> are "go get that thing and insert it here". But
>>>>>> often you want <ptr>s for other reasons, too. So it might be better
>>>>>> to put a @type on these <ptr>s to make this "inclusion" semantic
>>>>>> clear.
>>>>>>
>>>>>>> would like some feedback on the following:
>>>>>>>
>>>>>>> I’ve been trying to figure out a method that allows referencing the same
>>>>>>> photos from multiple files without having to repeat the figure element and
>>>>>>> all other encoded information.
>>>>>>>
>>>>>>> An example case  would be to re-use photos of  persons mentioned in
>>>>>>> different text or section of a project (or even different projects).
>>>>>>>
>>>>>>> After re-reading  section 16 Linking, Segmentation, and Alignment from the
>>>>>>> Guidelines and one of my initial scenarios would be:
>>>>>>>
>>>>>>> - create a  folder titled "media_photos" containing all the images
>>>>>>>
>>>>>>> - create a file titled "index_photos.xml" which is essentially a big list
>>>>>>> of "figure" elements containing references to the photos within the
>>>>>>> "media_photos" folder and some additional info such as captions,
>>>>>>> copyrights, descriptions. This would be the file that all other files would
>>>>>>> "target"
>>>>>>>
>>>>>>> - from another file e.g.  "somefile.xml" create a "prefixDef" with @ident
>>>>>>> attribute value set to e.g. "img"
>>>>>>>
>>>>>>> somewhere within the "somefile.xml" (let's say within a paragraph) an image
>>>>>>> would be referenced using e.g. a "ptr"  element with @target attribute
>>>>>>> value set to "img:someImage.png"
>>>>>>>
>>>>>>> I would be grateful for any suggestions/corrections or links to existing
>>>>>>> projects following a similar approach.
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Martin Holmes
Hi Peter,

It's exciting to hear that IIF is getting more involved with
transcription and encoding in addition to image handling. Does it do
tiling of large images automatically? I'm wondering if it might be a
useful alternative to e.g. OpenLayers 3, which is our current way of
handling large tiled images.

> Finally: if moving your images into IIIF is overkill when "all you
> want to do is link to some local images in an efficient way”, why is
> TEI/XML not also overkill?

I was assuming the questioner had a normal TEI encoding project with all
the usual reasons for using TEI to encode a transcription, and just
wanted to link images into the transcriptions.

Cheers,
Martin


On 2016-03-13 08:14 PM, Robinson, Peter wrote:

> Hi Martin I’ll admit to a hidden motive in my posting. IIIF is
> becoming a really significant player in the world of images and
> manuscripts. It is starting from multiple opposite ends from the
> TEI. IIIF begins with images and manuscripts.  It is intimately
> implementation-led. It uses JSON. The TEI begins with texts. It is
> implementation blind. It uses XML. However, the two worlds are
> moving towards each other. IIIF is looking at how better to handle
> the text of the documents it images. TEI (as your post shows) is
> exploring means of referencing quantities of images. There is already
> overlap between the two domains. I think there is a great deal of
> important work to be done in getting these two areas to work
> together.  Both do some things really well which the other does not.
> They are (and should be) complementary rather than opposed. So if
> this post alerts people in the TEI community to what is happening in
> IIIF, great.
>
> I’m also influenced by recent work in the textual communities
> project, where we decided to alter all our image handling from a
> TEI/XML base to IIIF (as part of our mass move to JSON as our
> fundamental document store — but retaining TEI for multiple critical
> operations). This has been more than enough to persuade us that a
> partnership of IIIF and TEI is really productive. Finally: if moving
> your images into IIIF is overkill when "all you want to do is link
> to some local images in an efficient way”, why is TEI/XML not also
> overkill? Yes, you need to install an IIIF server. But you need a
> server anyway. Of course, you can use vanilla apache — but the
> advantages of the IIIF server, optimized for handling tiled and
> scaled images, are really substantial. A humble suggestion. For
> sure, for some parts of this, TEI encoding will make sense. For
> other parts, IIIF (shared canvas) will make the best sense. Be kind
> of neat to use this instance to show how the two can work together.
> Just a suggestion. Peter
>
>
>> On Mar 13, 2016, at 3:06 PM, Martin Holmes <[hidden email]>
>> wrote:
>>
>> Hi Peter,
>>
>> If you're creating a website, and you have enough images of a large
>> enough scale to justify IIIF, then it makes sense. But I think this
>> was just a question about TEI encoding.
>>
>>> I guess if all you want is local delivery, then iiif would be
>>> overkill.  But then, so is XML/TEI.  Why not good old html?
>>
>> Well, I use TEI for scholarly encoding, and HTML for delivering an
>> output from that encoding to an HTML user-agent. I presume you're
>> not seriously suggesting that we do all our scholarly encoding in
>> HTML, are you? If so, the answer is that:
>>
>> a) It's not nuanced and rich enough;
>>
>> b) If you make it so by the use of e.g. custom data- attributes
>> and custom elements, you're just replicating in an idiosyncratic
>> and non-interoperable form the work of the TEI community.
>>
>> Cheers, Martin
>>
>>
>>
>> On 16-03-13 09:36 AM, Robinson, Peter wrote:
>>> Couple of points… 1. using IIIF.IO makes the images available
>>> through many different online viewers 2. the viewers, images and
>>> servers are optimized for web delivery etc I guess if all you
>>> want is local delivery, then iiif would be overkill.  But then,
>>> so is XML/TEI.  Why not good old html? Oh dear, now I went and
>>> said it. p
>>>> On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]>
>>>> wrote:
>>>>
>>>> On 16-03-12 04:35 PM, Robinson, Peter wrote:
>>>>> Look at iiif.io. I suspect shared canvas gives you all you
>>>>> want
>>>>
>>>> <quote>
>>>>
>>>> The basic steps to getting started with IIIF are:
>>>>
>>>> - Deploy an image server that supports the IIIF Image API
>>>>
>>>> - Publish metadata about your image-based objects that
>>>> complies to IIIF Presentation API
>>>>
>>>> - Deploy and integrate software that allows you to discover
>>>> and display IIIF-compliant image resources
>>>>
>>>> </quote> <ref target="http://iiif.io/technical-details/">IIIF
>>>> site</ref>
>>>>
>>>> That's a bit much when all you want to do is link to some
>>>> local images in an efficient way, surely?
>>>>
>>>> Cheers, Martin
>>>>
>>>>> Peter
>>>>>> On Mar 12, 2016, at 3:47 PM, Martin Holmes
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Any particular reason for choosing <ptr> over <graphic
>>>>>> url="img:someimage.png"/>? I think <graphic> makes more
>>>>>> sense, doesn't it?
>>>>>>
>>>>>> Cheers, Martin
>>>>>>
>>>>>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>>>>>> Would using XInclude suffice for your purpose?
>>>>>>>
>>>>>>> --------- excerpt of index_photos.xml ---------
>>>>>>>
>>>>>>> <figure xml:id="F03"> <figDesc>blah blah ...</figDesc>
>>>>>>> <graphic url="../media_photos/f03.jpg"/> <ab
>>>>>>> type="caption">blah blah ...</ab> </figure>
>>>>>>>
>>>>>>> --------- excerpt of somefile.xml ---------
>>>>>>>
>>>>>>> <xi:include href="./index_photos.xml"
>>>>>>> xpointer="element(F03)"> <xi:fallback><p>Unable to find
>>>>>>> F03!</p></xi:fallback> </xi:include>
>>>>>>>
>>>>>>> On a quick read the plan you sketched out sounds fine.
>>>>>>> The one missing bit that jumps to mind is the semantics
>>>>>>> of the <ptr>. If you have no other <ptr> elements, you
>>>>>>> can get away with just assuming the semantics of <ptr>
>>>>>>> are "go get that thing and insert it here". But often
>>>>>>> you want <ptr>s for other reasons, too. So it might be
>>>>>>> better to put a @type on these <ptr>s to make this
>>>>>>> "inclusion" semantic clear.
>>>>>>>
>>>>>>>> would like some feedback on the following:
>>>>>>>>
>>>>>>>> I’ve been trying to figure out a method that allows
>>>>>>>> referencing the same photos from multiple files
>>>>>>>> without having to repeat the figure element and all
>>>>>>>> other encoded information.
>>>>>>>>
>>>>>>>> An example case  would be to re-use photos of  persons
>>>>>>>> mentioned in different text or section of a project
>>>>>>>> (or even different projects).
>>>>>>>>
>>>>>>>> After re-reading  section 16 Linking, Segmentation,
>>>>>>>> and Alignment from the Guidelines and one of my
>>>>>>>> initial scenarios would be:
>>>>>>>>
>>>>>>>> - create a  folder titled "media_photos" containing
>>>>>>>> all the images
>>>>>>>>
>>>>>>>> - create a file titled "index_photos.xml" which is
>>>>>>>> essentially a big list of "figure" elements containing
>>>>>>>> references to the photos within the "media_photos"
>>>>>>>> folder and some additional info such as captions,
>>>>>>>> copyrights, descriptions. This would be the file that
>>>>>>>> all other files would "target"
>>>>>>>>
>>>>>>>> - from another file e.g.  "somefile.xml" create a
>>>>>>>> "prefixDef" with @ident attribute value set to e.g.
>>>>>>>> "img"
>>>>>>>>
>>>>>>>> somewhere within the "somefile.xml" (let's say within
>>>>>>>> a paragraph) an image would be referenced using e.g. a
>>>>>>>> "ptr"  element with @target attribute value set to
>>>>>>>> "img:someImage.png"
>>>>>>>>
>>>>>>>> I would be grateful for any suggestions/corrections or
>>>>>>>> links to existing projects following a similar
>>>>>>>> approach.
>>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Robinson, Peter
I’ll check the answer about IIIF and tiling.  We are currently implementing this within our setup (like, this minute).  I’ll check to see how we are doing this
peter

> On Mar 14, 2016, at 9:39 AM, Martin Holmes <[hidden email]> wrote:
>
> Hi Peter,
>
> It's exciting to hear that IIF is getting more involved with transcription and encoding in addition to image handling. Does it do tiling of large images automatically? I'm wondering if it might be a useful alternative to e.g. OpenLayers 3, which is our current way of handling large tiled images.
>
>> Finally: if moving your images into IIIF is overkill when "all you
>> want to do is link to some local images in an efficient way”, why is
>> TEI/XML not also overkill?
>
> I was assuming the questioner had a normal TEI encoding project with all the usual reasons for using TEI to encode a transcription, and just wanted to link images into the transcriptions.
>
> Cheers,
> Martin
>
>
> On 2016-03-13 08:14 PM, Robinson, Peter wrote:
>> Hi Martin I’ll admit to a hidden motive in my posting. IIIF is
>> becoming a really significant player in the world of images and
>> manuscripts. It is starting from multiple opposite ends from the
>> TEI. IIIF begins with images and manuscripts.  It is intimately
>> implementation-led. It uses JSON. The TEI begins with texts. It is
>> implementation blind. It uses XML. However, the two worlds are
>> moving towards each other. IIIF is looking at how better to handle
>> the text of the documents it images. TEI (as your post shows) is
>> exploring means of referencing quantities of images. There is already
>> overlap between the two domains. I think there is a great deal of
>> important work to be done in getting these two areas to work
>> together.  Both do some things really well which the other does not.
>> They are (and should be) complementary rather than opposed. So if
>> this post alerts people in the TEI community to what is happening in
>> IIIF, great.
>>
>> I’m also influenced by recent work in the textual communities
>> project, where we decided to alter all our image handling from a
>> TEI/XML base to IIIF (as part of our mass move to JSON as our
>> fundamental document store — but retaining TEI for multiple critical
>> operations). This has been more than enough to persuade us that a
>> partnership of IIIF and TEI is really productive. Finally: if moving
>> your images into IIIF is overkill when "all you want to do is link
>> to some local images in an efficient way”, why is TEI/XML not also
>> overkill? Yes, you need to install an IIIF server. But you need a
>> server anyway. Of course, you can use vanilla apache — but the
>> advantages of the IIIF server, optimized for handling tiled and
>> scaled images, are really substantial. A humble suggestion. For
>> sure, for some parts of this, TEI encoding will make sense. For
>> other parts, IIIF (shared canvas) will make the best sense. Be kind
>> of neat to use this instance to show how the two can work together.
>> Just a suggestion. Peter
>>
>>
>>> On Mar 13, 2016, at 3:06 PM, Martin Holmes <[hidden email]>
>>> wrote:
>>>
>>> Hi Peter,
>>>
>>> If you're creating a website, and you have enough images of a large
>>> enough scale to justify IIIF, then it makes sense. But I think this
>>> was just a question about TEI encoding.
>>>
>>>> I guess if all you want is local delivery, then iiif would be
>>>> overkill.  But then, so is XML/TEI.  Why not good old html?
>>>
>>> Well, I use TEI for scholarly encoding, and HTML for delivering an
>>> output from that encoding to an HTML user-agent. I presume you're
>>> not seriously suggesting that we do all our scholarly encoding in
>>> HTML, are you? If so, the answer is that:
>>>
>>> a) It's not nuanced and rich enough;
>>>
>>> b) If you make it so by the use of e.g. custom data- attributes
>>> and custom elements, you're just replicating in an idiosyncratic
>>> and non-interoperable form the work of the TEI community.
>>>
>>> Cheers, Martin
>>>
>>>
>>>
>>> On 16-03-13 09:36 AM, Robinson, Peter wrote:
>>>> Couple of points… 1. using IIIF.IO makes the images available
>>>> through many different online viewers 2. the viewers, images and
>>>> servers are optimized for web delivery etc I guess if all you
>>>> want is local delivery, then iiif would be overkill.  But then,
>>>> so is XML/TEI.  Why not good old html? Oh dear, now I went and
>>>> said it. p
>>>>> On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On 16-03-12 04:35 PM, Robinson, Peter wrote:
>>>>>> Look at iiif.io. I suspect shared canvas gives you all you
>>>>>> want
>>>>>
>>>>> <quote>
>>>>>
>>>>> The basic steps to getting started with IIIF are:
>>>>>
>>>>> - Deploy an image server that supports the IIIF Image API
>>>>>
>>>>> - Publish metadata about your image-based objects that
>>>>> complies to IIIF Presentation API
>>>>>
>>>>> - Deploy and integrate software that allows you to discover
>>>>> and display IIIF-compliant image resources
>>>>>
>>>>> </quote> <ref target="http://iiif.io/technical-details/">IIIF
>>>>> site</ref>
>>>>>
>>>>> That's a bit much when all you want to do is link to some
>>>>> local images in an efficient way, surely?
>>>>>
>>>>> Cheers, Martin
>>>>>
>>>>>> Peter
>>>>>>> On Mar 12, 2016, at 3:47 PM, Martin Holmes
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Any particular reason for choosing <ptr> over <graphic
>>>>>>> url="img:someimage.png"/>? I think <graphic> makes more
>>>>>>> sense, doesn't it?
>>>>>>>
>>>>>>> Cheers, Martin
>>>>>>>
>>>>>>> On 16-03-12 12:18 PM, Syd Bauman wrote:
>>>>>>>> Would using XInclude suffice for your purpose?
>>>>>>>>
>>>>>>>> --------- excerpt of index_photos.xml ---------
>>>>>>>>
>>>>>>>> <figure xml:id="F03"> <figDesc>blah blah ...</figDesc>
>>>>>>>> <graphic url="../media_photos/f03.jpg"/> <ab
>>>>>>>> type="caption">blah blah ...</ab> </figure>
>>>>>>>>
>>>>>>>> --------- excerpt of somefile.xml ---------
>>>>>>>>
>>>>>>>> <xi:include href="./index_photos.xml"
>>>>>>>> xpointer="element(F03)"> <xi:fallback><p>Unable to find
>>>>>>>> F03!</p></xi:fallback> </xi:include>
>>>>>>>>
>>>>>>>> On a quick read the plan you sketched out sounds fine.
>>>>>>>> The one missing bit that jumps to mind is the semantics
>>>>>>>> of the <ptr>. If you have no other <ptr> elements, you
>>>>>>>> can get away with just assuming the semantics of <ptr>
>>>>>>>> are "go get that thing and insert it here". But often
>>>>>>>> you want <ptr>s for other reasons, too. So it might be
>>>>>>>> better to put a @type on these <ptr>s to make this
>>>>>>>> "inclusion" semantic clear.
>>>>>>>>
>>>>>>>>> would like some feedback on the following:
>>>>>>>>>
>>>>>>>>> I’ve been trying to figure out a method that allows
>>>>>>>>> referencing the same photos from multiple files
>>>>>>>>> without having to repeat the figure element and all
>>>>>>>>> other encoded information.
>>>>>>>>>
>>>>>>>>> An example case  would be to re-use photos of  persons
>>>>>>>>> mentioned in different text or section of a project
>>>>>>>>> (or even different projects).
>>>>>>>>>
>>>>>>>>> After re-reading  section 16 Linking, Segmentation,
>>>>>>>>> and Alignment from the Guidelines and one of my
>>>>>>>>> initial scenarios would be:
>>>>>>>>>
>>>>>>>>> - create a  folder titled "media_photos" containing
>>>>>>>>> all the images
>>>>>>>>>
>>>>>>>>> - create a file titled "index_photos.xml" which is
>>>>>>>>> essentially a big list of "figure" elements containing
>>>>>>>>> references to the photos within the "media_photos"
>>>>>>>>> folder and some additional info such as captions,
>>>>>>>>> copyrights, descriptions. This would be the file that
>>>>>>>>> all other files would "target"
>>>>>>>>>
>>>>>>>>> - from another file e.g.  "somefile.xml" create a
>>>>>>>>> "prefixDef" with @ident attribute value set to e.g.
>>>>>>>>> "img"
>>>>>>>>>
>>>>>>>>> somewhere within the "somefile.xml" (let's say within
>>>>>>>>> a paragraph) an image would be referenced using e.g. a
>>>>>>>>> "ptr"  element with @target attribute value set to
>>>>>>>>> "img:someImage.png"
>>>>>>>>>
>>>>>>>>> I would be grateful for any suggestions/corrections or
>>>>>>>>> links to existing projects following a similar
>>>>>>>>> approach.
>>>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Robinson, Peter
In reply to this post by Martin Holmes
After a consultation with our TC programmer: indeed, IIIF *does* handle the tiling.  From http://iiif.io/technical-details/ you will see that IIIF offers currently two image servers, with more coming. We are using the Loris system on Ubuntu. This is exceptionally powerful.  Not only does it do the tiling, and support multiple viewers (including OpenSeaDragon, our choice), it also handles things like ‘tile upon demand’, caching of image and tile requests, etc. It deals with jpeg, jpeg 2000, tiff, png and gif out of the box.
And, of course, IIIF is there with shared canvas to cope with loads of metadata, etc etc

Peter

On Mar 14, 2016, at 9:39 AM, Martin Holmes <[hidden email]> wrote:

Hi Peter,

It's exciting to hear that IIF is getting more involved with transcription and encoding in addition to image handling. Does it do tiling of large images automatically? I'm wondering if it might be a useful alternative to e.g. OpenLayers 3, which is our current way of handling large tiled images.

Finally: if moving your images into IIIF is overkill when "all you
want to do is link to some local images in an efficient way”, why is
TEI/XML not also overkill?

I was assuming the questioner had a normal TEI encoding project with all the usual reasons for using TEI to encode a transcription, and just wanted to link images into the transcriptions.

Cheers,
Martin


On 2016-03-13 08:14 PM, Robinson, Peter wrote:
Hi Martin I’ll admit to a hidden motive in my posting. IIIF is
becoming a really significant player in the world of images and
manuscripts. It is starting from multiple opposite ends from the
TEI. IIIF begins with images and manuscripts.  It is intimately
implementation-led. It uses JSON. The TEI begins with texts. It is
implementation blind. It uses XML. However, the two worlds are
moving towards each other. IIIF is looking at how better to handle
the text of the documents it images. TEI (as your post shows) is
exploring means of referencing quantities of images. There is already
overlap between the two domains. I think there is a great deal of
important work to be done in getting these two areas to work
together.  Both do some things really well which the other does not.
They are (and should be) complementary rather than opposed. So if
this post alerts people in the TEI community to what is happening in
IIIF, great.

I’m also influenced by recent work in the textual communities
project, where we decided to alter all our image handling from a
TEI/XML base to IIIF (as part of our mass move to JSON as our
fundamental document store — but retaining TEI for multiple critical
operations). This has been more than enough to persuade us that a
partnership of IIIF and TEI is really productive. Finally: if moving
your images into IIIF is overkill when "all you want to do is link
to some local images in an efficient way”, why is TEI/XML not also
overkill? Yes, you need to install an IIIF server. But you need a
server anyway. Of course, you can use vanilla apache — but the
advantages of the IIIF server, optimized for handling tiled and
scaled images, are really substantial. A humble suggestion. For
sure, for some parts of this, TEI encoding will make sense. For
other parts, IIIF (shared canvas) will make the best sense. Be kind
of neat to use this instance to show how the two can work together.
Just a suggestion. Peter


On Mar 13, 2016, at 3:06 PM, Martin Holmes <[hidden email]>
wrote:

Hi Peter,

If you're creating a website, and you have enough images of a large
enough scale to justify IIIF, then it makes sense. But I think this
was just a question about TEI encoding.

I guess if all you want is local delivery, then iiif would be
overkill.  But then, so is XML/TEI.  Why not good old html?

Well, I use TEI for scholarly encoding, and HTML for delivering an
output from that encoding to an HTML user-agent. I presume you're
not seriously suggesting that we do all our scholarly encoding in
HTML, are you? If so, the answer is that:

a) It's not nuanced and rich enough;

b) If you make it so by the use of e.g. custom data- attributes
and custom elements, you're just replicating in an idiosyncratic
and non-interoperable form the work of the TEI community.

Cheers, Martin



On 16-03-13 09:36 AM, Robinson, Peter wrote:
Couple of points… 1. using IIIF.IO makes the images available
through many different online viewers 2. the viewers, images and
servers are optimized for web delivery etc I guess if all you
want is local delivery, then iiif would be overkill.  But then,
so is XML/TEI.  Why not good old html? Oh dear, now I went and
said it. p
On Mar 12, 2016, at 7:08 PM, Martin Holmes <[hidden email]>
wrote:

On 16-03-12 04:35 PM, Robinson, Peter wrote:
Look at iiif.io. I suspect shared canvas gives you all you
want

<quote>

The basic steps to getting started with IIIF are:

- Deploy an image server that supports the IIIF Image API

- Publish metadata about your image-based objects that
complies to IIIF Presentation API

- Deploy and integrate software that allows you to discover
and display IIIF-compliant image resources

</quote> <ref target="http://iiif.io/technical-details/">IIIF
site</ref>

That's a bit much when all you want to do is link to some
local images in an efficient way, surely?

Cheers, Martin

Peter
On Mar 12, 2016, at 3:47 PM, Martin Holmes
<[hidden email]> wrote:

Any particular reason for choosing <ptr> over <graphic
url="img:someimage.png"/>? I think <graphic> makes more
sense, doesn't it?

Cheers, Martin

On 16-03-12 12:18 PM, Syd Bauman wrote:
Would using XInclude suffice for your purpose?

--------- excerpt of index_photos.xml ---------

<figure xml:id="F03"> <figDesc>blah blah ...</figDesc>
<graphic url="../media_photos/f03.jpg"/> <ab
type="caption">blah blah ...</ab> </figure>

--------- excerpt of somefile.xml ---------

<xi:include href="./index_photos.xml"
xpointer="element(F03)"> <xi:fallback><p>Unable to find
F03!</p></xi:fallback> </xi:include>

On a quick read the plan you sketched out sounds fine.
The one missing bit that jumps to mind is the semantics
of the <ptr>. If you have no other <ptr> elements, you
can get away with just assuming the semantics of <ptr>
are "go get that thing and insert it here". But often
you want <ptr>s for other reasons, too. So it might be
better to put a @type on these <ptr>s to make this
"inclusion" semantic clear.

would like some feedback on the following:

I’ve been trying to figure out a method that allows
referencing the same photos from multiple files
without having to repeat the figure element and all
other encoded information.

An example case  would be to re-use photos of  persons
mentioned in different text or section of a project
(or even different projects).

After re-reading  section 16 Linking, Segmentation,
and Alignment from the Guidelines and one of my
initial scenarios would be:

- create a  folder titled "media_photos" containing
all the images

- create a file titled "index_photos.xml" which is
essentially a big list of "figure" elements containing
references to the photos within the "media_photos"
folder and some additional info such as captions,
copyrights, descriptions. This would be the file that
all other files would "target"

- from another file e.g.  "somefile.xml" create a
"prefixDef" with @ident attribute value set to e.g.
"img"

somewhere within the "somefile.xml" (let's say within
a paragraph) an image would be referenced using e.g. a
"ptr"  element with @target attribute value set to
"img:someImage.png"

I would be grateful for any suggestions/corrections or
links to existing projects following a similar
approach.




Reply | Threaded
Open this post in threaded view
|

Zotero TEI output bug

Charles Muller-5
I am guessing that the person who is handling the TEI module in Zotero
might be on this list.(?)

For the past couple of days when I try to do a TEI export from local
Zotero in Firefox 44.0.2/Win10, only the final item in a set of
bibliographical entries gets output to the XML file.

Regards,

Chuck

--

---------------------------
A. Charles Muller

Graduate School of Humanities and Sociology
Faculty of Letters
University of Tokyo
7-3-1 Hongō, Bunkyō-ku
Tokyo 113-8654, Japan

Office Phone: 03-5841-3735

Web Site: Resources for East Asian Language and Thought
http://www.acmuller.net

Twitter: @H_Buddhism
Reply | Threaded
Open this post in threaded view
|

Re: Creating an "index" of photos and referencing from multiple files

Frederik Elwert
In reply to this post by Aris Karatarakis-2
If you want to avoid XInclude, then I feel @copyOf would be what you
want in TEI:

> `@copyOf` points to an element of which the current element is a
> copy. Any content of the current element should be ignored. Its true
> content is that of the element being pointed at.

So you could have your complete `figure` element with caption and all in
index_photos.xml, and then re-use it:

<figure copyOf="index_photos.xml#figure123"/>

I think this has the advantage that the semantics of `ptr` are rather
vague, it just defines a pointer of some sorts. What you want is the
semantics of the `figure` element at every location, but just
de-duplicate the actual content. I think this is what `@copyOf` does.

Regards,
Frederik



Am 13.03.2016 um 15:59 schrieb Aris Karatarakis:

> Dear all,
>
> thank you all for your suggestions
>
> - no specific reason for choosing <ptr> element it was just an
> example, as mentioned @type would be used to clarify its usage - I
> avoided XInclude as in earlier versions of oXygen I experienced some
> slow down (haven’t tested it with the latest version) - iiif.io
> sounds very interesting, I will have a detailed look at it and
> perhaps use it at a later stage
>
> Best
>
> Aris
>

--
Dr. Frederik Elwert

Post-doctoral researcher
Project manager SeNeReKo
Center for Religious Studies
Ruhr-University Bochum

Universitätsstr. 90a
D-44780 Bochum

Room 2/206
Tel. +49-(0)234 - 32 23024