Quantcast

some questions about non-textual components and media

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

some questions about non-textual components and media

Saeed Sarrafzadeh
Hi all
Excuse me if my questions seems answered somewhere, but I couldn't find them (after reading the relevant parts of guidelines and searching the list for similar questions).
As I understand from the guidelines, one can include a picture or video using the <graphic> element. Is it impossible to include an audio file in an article or e-book? How one can include an audio file in a text. Also, some texts of great importance may be a subject of teaching for some famous scholars which may be treated as a teaching of parts of the main text or some vocal  comments or description or so about parts of text. How one can encode such features using the TEI?
Thank you so much
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Syd Bauman
[Heh-heh. I've been expecting this question ... :-]

I think the answer is yes, you *can* encode a pointer to an audio
file using <graphic>. There are three problems, though.

1) The tactical semantics are incorrect. Even though to a casual
   reader it is clear that
      <graphic url="../sound/I_Have_a_Dream.ogg"
               mimeType="audio/ogg" />
   refers to an audio file, the Guidelines clearly state that
   <graphic> is for "an inline graphic, illustration, or figure".

2) The attributes are incorrect. <graphic> has, e.g., height= and
   width=, but does not have dur=.

3) The strategic semantics are probably incorrect. I'm not sure of
   your situation, but remember that the TEI is primarily about
   encoding extant texts. (Which is not to say we don't use it for
   born-digital stuff, we do.) So the <graphic> element is primarily
   intended to represent a graphic that exists in an existing
   physical document. (E.g.,
   http://www.sffaudio.com/images08/flatland500.jpg.) So if what
   you're doing is adding a pointer to something else, e.g., to an
   audio instantiation of the current document, or a commentary on
   it, then encoding with <figure> and <graphic> may not be the right
   thing to do anyway.

In any case, I'd recommend either:

A) Using <ptr>:
      <ptr type="facsimile"
           subtype="audio"
           target="../sound/I_Have_a_Dream.ogg"
           mimeType="audio/ogg" />

B) Customizing TEI as to create a new <my:audio> element that is much
   like <graphic>, but has correct semantics and attrs.

Other possibilities (which I'm not as fond of) are to abuse the
<graphic> element or the facs= attribute.


> Hi all Excuse me if my questions seems answered somewhere, but I
> couldn't find them (after reading the relevant parts of guidelines
> and searching the list for similar questions). As I understand from
> the guidelines, one can include a picture or video using the
> <graphic> element. Is it impossible to include an audio file in an
> article or e-book? How one can include an audio file in a text.
> Also, some texts of great importance may be a subject of teaching
> for some famous scholars which may be treated as a teaching of
> parts of the main text or some vocal comments or description or so
> about parts of text. How one can encode such features using the
> TEI? Thank you so much
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Laurent Romary
Am I off-topic or a possible solution would be to identify these excerpts as transcriptions from an audio file and than use the corresponding TEI tools to point to the underlying audio file:
- <facsimile> to record the audio file
- <timeline> to define the temporal entry points in the files
- <u> to put in the transcription (or not) and refer to the timeline
I am sure I will have a couple of friends :-}
Laurent

Le 17 déc. 2012 à 15:01, Syd Bauman a écrit :

> [Heh-heh. I've been expecting this question ... :-]
>
> I think the answer is yes, you *can* encode a pointer to an audio
> file using <graphic>. There are three problems, though.
>
> 1) The tactical semantics are incorrect. Even though to a casual
>   reader it is clear that
>      <graphic url="../sound/I_Have_a_Dream.ogg"
>               mimeType="audio/ogg" />
>   refers to an audio file, the Guidelines clearly state that
>   <graphic> is for "an inline graphic, illustration, or figure".
>
> 2) The attributes are incorrect. <graphic> has, e.g., height= and
>   width=, but does not have dur=.
>
> 3) The strategic semantics are probably incorrect. I'm not sure of
>   your situation, but remember that the TEI is primarily about
>   encoding extant texts. (Which is not to say we don't use it for
>   born-digital stuff, we do.) So the <graphic> element is primarily
>   intended to represent a graphic that exists in an existing
>   physical document. (E.g.,
>   http://www.sffaudio.com/images08/flatland500.jpg.) So if what
>   you're doing is adding a pointer to something else, e.g., to an
>   audio instantiation of the current document, or a commentary on
>   it, then encoding with <figure> and <graphic> may not be the right
>   thing to do anyway.
>
> In any case, I'd recommend either:
>
> A) Using <ptr>:
>      <ptr type="facsimile"
>           subtype="audio"
>           target="../sound/I_Have_a_Dream.ogg"
>           mimeType="audio/ogg" />
>
> B) Customizing TEI as to create a new <my:audio> element that is much
>   like <graphic>, but has correct semantics and attrs.
>
> Other possibilities (which I'm not as fond of) are to abuse the
> <graphic> element or the facs= attribute.
>
>
>> Hi all Excuse me if my questions seems answered somewhere, but I
>> couldn't find them (after reading the relevant parts of guidelines
>> and searching the list for similar questions). As I understand from
>> the guidelines, one can include a picture or video using the
>> <graphic> element. Is it impossible to include an audio file in an
>> article or e-book? How one can include an audio file in a text.
>> Also, some texts of great importance may be a subject of teaching
>> for some famous scholars which may be treated as a teaching of
>> parts of the main text or some vocal comments or description or so
>> about parts of text. How one can encode such features using the
>> TEI? Thank you so much

Laurent Romary
INRIA & HUB-IDSL
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey
In reply to this post by Syd Bauman
I'd have thought <binaryObject> was the obvious answer.

-- JPM

On 12/17/2012 9:01 AM, Syd Bauman wrote:
[Heh-heh. I've been expecting this question ... :-]

I think the answer is yes, you *can* encode a pointer to an audio
file using <graphic>. There are three problems, though.

1) The tactical semantics are incorrect. Even though to a casual
   reader it is clear that
      <graphic url="../sound/I_Have_a_Dream.ogg"
               mimeType="audio/ogg" />
   refers to an audio file, the Guidelines clearly state that
   <graphic> is for "an inline graphic, illustration, or figure".

2) The attributes are incorrect. <graphic> has, e.g., height= and
   width=, but does not have dur=.

3) The strategic semantics are probably incorrect. I'm not sure of
   your situation, but remember that the TEI is primarily about
   encoding extant texts. (Which is not to say we don't use it for
   born-digital stuff, we do.) So the <graphic> element is primarily
   intended to represent a graphic that exists in an existing
   physical document. (E.g.,
   http://www.sffaudio.com/images08/flatland500.jpg.) So if what
   you're doing is adding a pointer to something else, e.g., to an
   audio instantiation of the current document, or a commentary on
   it, then encoding with <figure> and <graphic> may not be the right
   thing to do anyway.

In any case, I'd recommend either:

A) Using <ptr>:
      <ptr type="facsimile"
           subtype="audio"
           target="../sound/I_Have_a_Dream.ogg"
           mimeType="audio/ogg" />

B) Customizing TEI as to create a new <my:audio> element that is much
   like <graphic>, but has correct semantics and attrs.

Other possibilities (which I'm not as fond of) are to abuse the
<graphic> element or the facs= attribute.


Hi all Excuse me if my questions seems answered somewhere, but I
couldn't find them (after reading the relevant parts of guidelines
and searching the list for similar questions). As I understand from
the guidelines, one can include a picture or video using the
<graphic> element. Is it impossible to include an audio file in an
article or e-book? How one can include an audio file in a text.
Also, some texts of great importance may be a subject of teaching
for some famous scholars which may be treated as a teaching of
parts of the main text or some vocal comments or description or so
about parts of text. How one can encode such features using the
TEI? Thank you so much

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey
Here are a couple examples of using base64 to encode audio:
http://stackoverflow.com/questions/2270151/is-it-possible-to-use-data-uris-in-video-and-audio-tags



On 12/17/2012 10:12 AM, John P. McCaskey wrote:
I'd have thought <binaryObject> was the obvious answer.

-- JPM

On 12/17/2012 9:01 AM, Syd Bauman wrote:
[Heh-heh. I've been expecting this question ... :-]

I think the answer is yes, you *can* encode a pointer to an audio
file using <graphic>. There are three problems, though.

1) The tactical semantics are incorrect. Even though to a casual
   reader it is clear that
      <graphic url="../sound/I_Have_a_Dream.ogg"
               mimeType="audio/ogg" />
   refers to an audio file, the Guidelines clearly state that
   <graphic> is for "an inline graphic, illustration, or figure".

2) The attributes are incorrect. <graphic> has, e.g., height= and
   width=, but does not have dur=.

3) The strategic semantics are probably incorrect. I'm not sure of
   your situation, but remember that the TEI is primarily about
   encoding extant texts. (Which is not to say we don't use it for
   born-digital stuff, we do.) So the <graphic> element is primarily
   intended to represent a graphic that exists in an existing
   physical document. (E.g.,
   http://www.sffaudio.com/images08/flatland500.jpg.) So if what
   you're doing is adding a pointer to something else, e.g., to an
   audio instantiation of the current document, or a commentary on
   it, then encoding with <figure> and <graphic> may not be the right
   thing to do anyway.

In any case, I'd recommend either:

A) Using <ptr>:
      <ptr type="facsimile"
           subtype="audio"
           target="../sound/I_Have_a_Dream.ogg"
           mimeType="audio/ogg" />

B) Customizing TEI as to create a new <my:audio> element that is much
   like <graphic>, but has correct semantics and attrs.

Other possibilities (which I'm not as fond of) are to abuse the
<graphic> element or the facs= attribute.


Hi all Excuse me if my questions seems answered somewhere, but I
couldn't find them (after reading the relevant parts of guidelines
and searching the list for similar questions). As I understand from
the guidelines, one can include a picture or video using the
<graphic> element. Is it impossible to include an audio file in an
article or e-book? How one can include an audio file in a text.
Also, some texts of great importance may be a subject of teaching
for some famous scholars which may be treated as a teaching of
parts of the main text or some vocal comments or description or so
about parts of text. How one can encode such features using the
TEI? Thank you so much


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Syd Bauman
In reply to this post by John P. McCaskey
LR> Am I off-topic or a possible solution would be to identify these
LR> excerpts as transcriptions from an audio file and than use the
LR> corresponding TEI tools to point to the underlying audio file:
LR> - <facsimile> to record the audio file
LR> - <timeline> to define the temporal entry points in the files
LR> - <u> to put in the transcription (or not) and refer to the timeline
LR> I am sure I will have a couple of friends :-}

Absolutely! I would be a friend to this general approach if the OP
wants to transcribe the audio. (I was under the impression that was
not the case.)


JPM> I'd have thought <binaryObject> was the obvious answer.

Yes, <binaryObject> "works" in the sense that it has looser semantics
than <graphic>, but
a) also has attrs one would not want, and missing some you might, and
b) requires that you put the sound file inline, which may be
   undesirable.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey
On 12/17/2012 10:29 AM, Syd Bauman wrote:
JPM> I'd have thought <binaryObject> was the obvious answer.

Yes, <binaryObject> "works" in the sense that it has looser semantics than <graphic>, but 
a) also has attrs one would not want, and missing some you might, and
b) requires that you put the sound file inline, which may be undesirable.
Of course one needn't use inapplicable attributes. Though even here, an encoder might very well want to specify the height and width of a media player.

Yes it might be nice to have some other attributes for different media. Should some common ones be formally added to the guidelines? @dur? @duration? @bitrate?

If the encoder didn't want to include even an excerpt of the sound file inline (though the original question did ask about "including" the file in the text), plenty of good pointing attributes are right there in <binaryObject> already.

Use of <binaryObject> requires no unnatural acts. The definition specifically allows "binary data representing an inline graphic OR OTHER OBJECT" and describes how to specify the MIME type.

I say, all hail <binaryObject>!
--


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Sebastian Rahtz-3
On 17 Dec 2012, at 15:50, John P. McCaskey <[hidden email]> wrote:
>>
> Of course one needn't use inapplicable attributes. Though even here, an encoder might very well want to specify the height and width of a media player.
>
> Yes it might be nice to have some other attributes for different media. Should some common ones be formally added to the guidelines? @dur? @duration? @bitrate?
>
we could make <graphic> a member of att. duration and so acquire @dur

>
> Use of <binaryObject> requires no unnatural acts. The definition specifically allows "binary data representing an inline graphic OR OTHER OBJECT" and describes how to specify the MIME type.
>
> I say, all hail <binaryObject>!

i would suggest that for many people, encoding and embedding a sound file, and writing code
to extract and decode it again, is fairly non-trivial. You can't do it in XSLT, for example, I think.

--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey
On 12/17/2012 10:54 AM, Sebastian Rahtz wrote:
we could make <graphic> a member of att. duration and so acquire @dur
I suggest making <binaryObject> instead of <graphic> the member of att.duration.

i would suggest that for many people, encoding and embedding a sound file, and writing code to extract and decode it again, is fairly non-trivial. You can't do it in XSLT, for example, I think.
Once saved as base64, the sound file is just a string. Once it got put into TEI, it would just be a text node and XSLT would have no problem with it, just as it has no problem with base64-encoded images in <binaryObject> now. And browsers can render base64-encoded sounds just as they do base64-encoded images.

By the way, whose face is that encoded in the <binaryObject> example in the Guidelines?

-- JPM
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Sebastian Rahtz-3
On 17 Dec 2012, at 16:05, "John P. McCaskey" <[hidden email]>
 wrote:

> On 12/17/2012 10:54 AM, Sebastian Rahtz wrote:
>> we could make <graphic> a member of att. duration and so acquire @dur
> I suggest making <binaryObject> instead of <graphic> the member of att.duration.
>
fair point. can you make a ticket in Sourceforge?

>> i would suggest that for many people, encoding and embedding a sound file, and writing code to extract and decode it again, is fairly non-trivial. You can't do it in XSLT, for example, I think.
> Once saved as base64, the sound file is just a string. Once it got put into TEI, it would just be a text node and XSLT would have no problem with it, just as it has no problem with base64-encoded images in <binaryObject> now. And browsers can render base64-encoded sounds just as they do base64-encoded images.
>
oh, can they? I am behind the times.

> By the way, whose face is that encoded in the <binaryObject> example in the Guidelines?


Charles Goldfarb, at a wild guess.


--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Saeed Sarrafzadeh
In reply to this post by Saeed Sarrafzadeh
Hi
Thanks to Syd, Laurent, John, and others. As I noted in my previous post, I don't think that  the <graphic> element may be an approriate practice in this regard and I only point to it as a mechanism which is designed in TEI and I thought the lack of a similar mechanism for audio type files. This seems also the case for using <facsimile> element which (as I noted) is specially for graphic objects containing the source text. The <binaryObject>, although its definition may seems compatible with an audio file, and its content model may let us do that, but it seems specifically designed for a graphic type object (especially when we take a look at its special attributes). But, if we have no other option in hand it may be reasonable and somewhat preferrable to use it for inline audio which may be the case for some books in linguistics, phonology or so in the near future (I think that it may be better than adding a new element for myself).
I've also some problem with the <ptr/> practice. As I noticed from the guidelines it can be used if there exists some type of explicit referencing which is not the case here (am I right?).
Please let me know about the best practice you suggest in this regard. Also I'd be gratefull if you point to my mistakes if you think that I've mistaken (about your suggested approach or so).
Again, I want to recall the second case: the texts of great importance which may be a subject of teaching for some famous scholars which may be treated as a teaching of parts of the main text or some vocal comments or description or so about parts of text. Is it feasible to mark that part of text with <seg> element (if it's not marked with another element) and using corresp or ana attributes? Isn't that an abuse of these attributes? Is there exist any other practice? Does you think that the TEI may expand itself in this regard?
Again, I should excuse all of the list members because of my bad english composition and some silly questions.
Best regards, Saeed
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey
In reply to this post by Sebastian Rahtz-3
On 12/17/2012 11:14 AM, Sebastian Rahtz wrote:
On 12/17/2012 10:54 AM, Sebastian Rahtz wrote:
>> we could make <graphic> a member of att. duration and so acquire @dur
> I suggest making <binaryObject> instead of <graphic> the member of att.duration.
fair point. can you make a ticket in Sourceforge?

Done.

-- JPM
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Syd Bauman
In reply to this post by Sebastian Rahtz-3
> fair point. can you make a ticket in Sourceforge?

While I'm not at all against adding <binaryObject> to att.duration,
it doesn't solve the major point that use of <binaryObject> requires
that the binary object itself (instead of a pointer to it) be placed
in the TEI encoding. This makes it untenable for most uses, I think.
E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
it is 13.6 MiB. That makes managing your TEI file a big pain.
Besides, what if you wanted that speech in several different TEI
files?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Sebastian Rahtz-3
On 17 Dec 2012, at 16:29, Syd Bauman <[hidden email]>
 wrote:

> it doesn't solve the major point that use of <binaryObject> requires
> that the binary object itself (instead of a pointer to it) be placed
> in the TEI encoding. This makes it untenable for most uses, I think.
> E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
> it is 13.6 MiB. That makes managing your TEI file a big pain.
> Besides, what if you wanted that speech in several different TEI
> files?


XInclude is your friend :-}
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

McAulay, Elizabeth
In reply to this post by Syd Bauman
A lot of this discussion is more advanced than I am, so I'll speak as a more lay practitioner. And I apologize to Saeed if I distract from his original questions

In my encoding of materials with related or integral images and audio materials, I prefer to use a pointing mechanism rather than embed actual binary objects / files into my XML. For example, with an oral history, we see the transcript and the audio recording as two files that work together.

I do think having a clear example of referencing external audio and video files (and other stuff, too) in the same way we have done for image files would be helpful.

I hope my comments help add to the use case scenario, even if they don't answer Saeed's questions!

Best,
Lisa


-------------------------------------
Elizabeth "Lisa" McAulay
Librarian for Digital Collection Development
UCLA Digital Library Program
http://digital.library.ucla.edu/
email: emcaulay [at] library.ucla.edu
________________________________________
From: TEI (Text Encoding Initiative) public discussion list [[hidden email]] on behalf of Syd Bauman [[hidden email]]
Sent: Monday, December 17, 2012 8:29 AM
To: [hidden email]
Subject: Re: some questions about non-textual components and media

> fair point. can you make a ticket in Sourceforge?

While I'm not at all against adding <binaryObject> to att.duration,
it doesn't solve the major point that use of <binaryObject> requires
that the binary object itself (instead of a pointer to it) be placed
in the TEI encoding. This makes it untenable for most uses, I think.
E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
it is 13.6 MiB. That makes managing your TEI file a big pain.
Besides, what if you wanted that speech in several different TEI
files?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Martin Holmes
In reply to this post by Sebastian Rahtz-3
On 12-12-17 08:34 AM, Sebastian Rahtz wrote:

> On 17 Dec 2012, at 16:29, Syd Bauman <[hidden email]>
>   wrote:
>
>> it doesn't solve the major point that use of <binaryObject> requires
>> that the binary object itself (instead of a pointer to it) be placed
>> in the TEI encoding. This makes it untenable for most uses, I think.
>> E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
>> it is 13.6 MiB. That makes managing your TEI file a big pain.
>> Besides, what if you wanted that speech in several different TEI
>> files?
>
>
> XInclude is your friend :-}

I must admit I agree with Syd here: XIncluding a huge binary file is not
really practical (it'll probably make validation painfully slow, for one
thing).

The question is whether using our existing generic pointing mechanisms
is perfectly fine, as in Syd's example with <ptr>, or whether we need
something more syntactic-sugary, analogous with the <graphic> object. If
the former, we should at least include a couple of examples in the
Guidelines.

Cheers,
Martin

> --
> Sebastian Rahtz
> Director (Research Support) of Academic IT Services
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>

--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
([hidden email])
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

John P. McCaskey


On 12/17/2012 12:56 PM, Martin Holmes wrote:
On 12-12-17 08:34 AM, Sebastian Rahtz wrote:
On 17 Dec 2012, at 16:29, Syd Bauman [hidden email]
  wrote:

it doesn't solve the major point that use of <binaryObject> requires
that the binary object itself (instead of a pointer to it) be placed
in the TEI encoding. This makes it untenable for most uses, I think.
E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
it is 13.6 MiB. That makes managing your TEI file a big pain.
Besides, what if you wanted that speech in several different TEI
files?

XInclude is your friend :-}

I must admit I agree with Syd here: XIncluding a huge binary file is not really practical (it'll probably make validation painfully slow, for one thing).

The question is whether using our existing generic pointing mechanisms is perfectly fine, as in Syd's example with <ptr>, or whether we need something more syntactic-sugary, analogous with the <graphic> object. If the former, we should at least include a couple of examples in the Guidelines.

Cheers,
Martin


When a binary object -- image, animation, audio, video, whatever -- is small enough (and the encoding project warrants this), the object can be base-64 encoded and put into a <binaryObject>.

When the object's size (or just the project's asset management practice) precludes embedding, then an image file can be referenced in <graphic>. The question is what is the analog to <graphic> for audio, video, etc.?

Does/Could/Should <recording> be part of the answer?

-- JPM



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Lou Burnard-6
Sorry, I have been offline most of today, so only just catching up with
this discussion.

At first, it seemed pretty self0evident that there is a strong case for
providing an <audio> element exactly analogous to the existing <graphic>
element, but with the implication that it points to an audio
representation rather than a static image.

Then I wondered whether we might not instead want something more generic
== say <media> so we could use it also to point to a video. Either way
it makes sense to give it its own specialised attributes, notably for
duration but also presumably others.


|When a binary object -- image, animation, audio, video, whatever -- is
small enough (and the encoding project warrants this), the object can be
base-64 encoded and put into a |<binaryObject>.

Like others, I think that;s largely irrelevant to this use case

>
> When the object's size (or just the project's asset management
> practice) precludes embedding, then an image file can be referenced in
> <graphic>. The question is what is the analog to <graphic> for audio,
> video, etc.?
>
> Does/Could/Should <recording> be part of the answer?
>
  <recording> is for documenting information about how a recording was
made, not for pointing to an MP4 or whatever containing the actual
recording.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Saeed Sarrafzadeh
In reply to this post by Saeed Sarrafzadeh
Hi all
On Mon, 17 Dec 2012 16:52:45 +0000, McAulay, Elizabeth <[hidden email]> wrote:

>A lot of this discussion is more advanced than I am, so I'll speak as a more lay practitioner. And I apologize to Saeed if I distract from his original questions

I'm really grateful for participating in this topic. This list discussions are all more advanced than I am, and I'm really grateful to all participants for accepting some discussion with a beginner like me.

>In my encoding of materials with related or integral images and audio materials, I prefer to use a pointing mechanism rather than embed actual binary objects / files into my XML. For example, with an oral history, we see the transcript and the audio recording as two files that work together.

In the case of transcription of an speech it seems feasible to point from a newly composed object (the transcription) to the source object, but I think that it may be better to use more appropriate mechanisms in the guidelines (the transcription of speech part) to do that, because we make a claim in any pointing about a referring from the text to another object. Also, I think that if we want to use more general approaches, it'll be better to use a note which refers the reader from that point to an specified audio file. Your suggestion is also a good practice for cases where we want to talk about a sample or example.


Again I should thank you for sharing your experience here.

Best regards, Saeed
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: some questions about non-textual components and media

Saeed Sarrafzadeh
In reply to this post by Saeed Sarrafzadeh
On Mon, 17 Dec 2012 09:56:16 -0800, Martin Holmes <[hidden email]> wrote:

>On 12-12-17 08:34 AM, Sebastian Rahtz wrote:
>> On 17 Dec 2012, at 16:29, Syd Bauman <[hidden email]>
>>   wrote:
>>
>>> it doesn't solve the major point that use of <binaryObject> requires
>>> that the binary object itself (instead of a pointer to it) be placed
>>> in the TEI encoding. This makes it untenable for most uses, I think.
>>> E.g., the OGG file for "I Have a Dream" is 10.1 MiB; base-64 encoded
>>> it is 13.6 MiB. That makes managing your TEI file a big pain.
>>> Besides, what if you wanted that speech in several different TEI
>>> files?
>>
>>
>> XInclude is your friend :-}
>
>I must admit I agree with Syd here: XIncluding a huge binary file is not
>really practical (it'll probably make validation painfully slow, for one
>thing).
>
>The question is whether using our existing generic pointing mechanisms
>is perfectly fine, as in Syd's example with <ptr>, or whether we need
>something more syntactic-sugary, analogous with the <graphic> object. If
>the former, we should at least include a couple of examples in the
>Guidelines.
>
>Cheers,
>Martin
>
>> --
>> Sebastian Rahtz
>> Director (Research Support) of Academic IT Services
>> University of Oxford IT Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>
>--
>Martin Holmes
>University of Victoria Humanities Computing and Media Centre
>([hidden email])

Hi all
Thanks again to Syd and John for their useful notions and to Sebastian and Martin for their participation in this topic.
As Syd noted handling a huge binary file is not practical now, but I think that when we're thinking about an standard approach we should adopt the cases in near future: it may be the case for the future to handle such an objects! Again I should note that in some cases (especially in linguistic study cases or in some other studies which are related to sound editing, sampling and ...) we may face with some small pieces of audio types which can be included in some new type of books or tutorials. That's why I asked in my first post as the first question about the possibility of such cases.
Best regards, Saeed
12
Loading...