Re: LIFT href values for illustration and media (FLEX export)
Martin Hosken
I think that a better approach, rather than forcing applications to know which directories to look in, is to say that the relative path to any hrefed file is relative to the location of the .lift file. Thus if one were to say href="audio/house.wav" or href="media/house.wav" the reader will know what to do. (I follow the same relative syntax as html href here, so I think it's forward slash all the time?) This way, there is no need to enshrine any particular paths in the standard. I would be very happy to add that all paths are relative to the .lift file itself, and I really do think that would solve the problem.
What is the requirement for writers? That they keep media items in the same relative location? Or can they move them? My initial thought would be to allow them to move, but that could make merging more interesting. So I am open on this one to you guys.
BTW can we please have these discussions on the lexiconinterchangeformat list?
TIA,
GB,
Martin
> Note the Audio subdirectory is only in the WeSay LIFT folder. Flex uses ‘Media’ as the subdirectory we normally use since these files may be video clips of a speaker as well as sound files.
>
>
>
> If the user does not choose to copy picture/media files to the Lift directory (some won’t want to because the huge size media files can be) the LIFT file contains the links we normally have in FieldWorks, so you should continue to support this in Lexique Pro if Sound/Audio directories are not available in the LIFT directory.
>
>
>
> Ken
>
>
>
> From: Stephen_...@sil.org [mailto:Stephen_...@sil.org]
> Sent: Tuesday, May 19, 2009 11:51 AM
> To: Richard Margetts
> Cc: John Hatton; ken_...@sil.org; martin...@sil.org; Susann...@sil.org
> Subject: Re: LIFT href values for illustration and media (FLEX export)
>
>
>
>
> Richard,
> As John said in his message, Lexique Pro 3.1 is handling pictures properly by looking in the "pictures" subdirectory adjacent to the LIFT file. This works for both WeSay, and for (the upcoming release of) Flex. So I don't think you need to do anything more about pictures for LIFT. :-)
>
> As for sound (or video?) files, WeSay also has an "audio" subdirectory for storing sound files, and the upcoming release of Flex will (be able to) copy any sound or video files it uses to a subdirectory of that name. However, the two programs handle links to these files very differently.
> Flex mostly links to sound/video files through the pronunciation objects owned by a lex entry. These are represented in LIFT as follows:
>
> <entry dateCreated="2009-01-30T16:55:35Z" ... id="house_5e8f0e95-4249-4757-a97b-f8e83c6eac43">
> <lexical-unit>
> <form lang="x-kal"><text>house</text></form>
> </lexical-unit>
> ...
> <pronunciation>
> <media href="house.wav"></media>
> </pronunciation>
> <sense id="shelter_00db1003-3bbb-48ba-a2ae-6deb10b8a333" order="1">
> ...
> </sense>
> </entry>
>
> Note that the href attribute of the media element is interpreted the same as the href attribute of an illustration element, except that the file is found in the audio subdirectory instead of the pictures subdirectory.
> There is another way for Flex to link to sound files by imposing a hyperlink over a section of text, but currently no attempt is made to copy files linked in this way to the audio subdirectory. The href attribute of the span element inside a string looks more like a real URI. I don't think WeSay handles such hyperlinks, although the WeSay team could surprise me... :-) The data would look something like this:
>
> <entry dateCreated="2009-01-30T16:55:35Z" dateModified="2009-05-15T19:24:05Z" guid="5e8f0e95-4249-4757-a97b-f8e83c6eac43" id="house_5e8f0e95-4249-4757-a97b-f8e83c6eac43">
> <lexical-unit>
> <form lang="x-kal"><text>house</text></form>
> </lexical-unit>
> ...
> <sense id="shelter_00db1003-3bbb-48ba-a2ae-6deb10b8a333" order="1">
> ...
> <example>
> <form lang="x-kal"><text>This is an old <span href="file://C:/Documents and Settings/mcconnel/My Documents/My Sounds/house.wav" class="Hyperlink">house</span>.</text></form>
> </example>
> ...
> </sense>
> </entry>
>
> As you have noticed, WeSay is using audio information stored via a specially marked writing system, allowing audio information to be stored almost anywhere. You'll have to sort out with the WeSay team how much of that functionality to support. Flex currently imports that data, but makes no attempt to link up the sound files for actual use. (That may change eventually, but probably not any time soon.)
>
> I'm attaching a zip file containing a sample Flex export that includes the above examples, with one sound file and two pictures. I've verified that the pictures are displayed properly by Lexique Pro 3.1.
>
> --
> Steve McConnel
>
>
>
>
>
> Richard Margetts <richard_...@sil.org>
>
> 05/18/2009 04:22 AM
>
>
> To
>
> John Hatton <john_...@sil.org>
>
>
> cc
>
> Stephen_...@sil.org, ken_...@sil.org, Susann...@sil.org, martin...@sil.org
>
>
> Subject
>
> Re: LIFT href values for illustration and media (FLEX export)
>
>
>
>
>
>
>
>
> Hi Steve, John,
>
> I would be happy to modify Lexique Pro to look in the right places for pictures and audio.
>
> Please could someone give me a specification and a few sample LIFT files to help me know what is required.
>
> I am not exactly sure what the standard is for links to audio files in LIFT. I had thought it was with the "media" element, but I see that audio info is sometimes being defined as a writing system. The LIFT_13 document doesn't give any examples as far as I can see.
>
> Thanks for any clarifications you can give on this.
>
> Richard
>
>
> John Hatton wrote:
> This is timely! Richard just announced to me LP 3.1. I got it, and it properly handles pictures without paths, as used by WeSay exported from FLEx. I think we can now officially say, this is the LIFT standard way. Again… through everone’s cooperation, LIFT has moved from simply a file standard, to a *folder standard*. I’m happy!
>
> As for audio, I’m not sure… in my quick look, LP 3.1 didn’t recognize the fields that had audio (the contents a file name ending in .wav (someday , .mp3, .ogg)) as such, it just listed the filename.
>
> JH
>
> From: <mailto:Stephen_...@sil.org> Stephen_...@sil.org [ <mailto:Stephen_...@sil.org> mailto:Stephen_...@sil.org]
> Sent: Saturday, May 16, 2009 9:34 AM
> To: <mailto:john_...@sil.org> john_...@sil.org
> Cc: <mailto:ken_...@sil.org> ken_...@sil.org; <mailto:Susann...@sil.org> Susann...@sil.org; <mailto:martin...@sil.org> martin...@sil.org; <mailto:richard_...@sil.org> richard_...@sil.org
> Subject: LIFT href values for illustration and media (FLEX export)
>
>
> John et al.,
> We have a JIRA issue (LT-9236) that complains that Lexique Pro can't pick up on the picture (and sound) files exported from Flex in LIFT files. It's quite possible that Lexique Pro is expecting full pathnames, since that's what Flex used to output.
> The current export behavior of Flex (6.0) is to look for subdirectories named "pictures" and "audio" in the directory where the LIFT file is being written. If those directories exist, any pictures or media files that do not already exist in those directories are copied there. If either of those directories do not exist, the corresponding set of files are not copied, but only the bare filenames are written to the LIFT file. Nothing in the GUI suggests this behavior to the user, it just works that way. This was done to make exporting to an existing WeSay project transparent. (Of course, the different ways WeSay and Flex have implemented sound files prevents their actual interchange from being useful, but...)
> What I'm thinking of doing is providing users with a 2-way radio button option on export (the wording is still up in the air):
>
> * WeSay export - creating the subdirectories if they don't already exist
> * Lexique Pro export - writing the filenames as full pathnames in the LIFT file.
>
> An alternative, if Lexique Pro can be changed to look for the pictures / sound files in the subdirectories all the time, would be a check box to enable creating the directories if desired, but always writing the links as bare filenames as it does now.
> I would appreciate feedback soon on what the best approach is. I would tend to favor the latter (single checkbox), but that requires a change to Lexique Pro (which might be desireable anyway), and I'm not at all a user interface expert. There may well be a third alternative superior to either of these!
> Having proper information in the LIFT file to resolve these links is a tricky issue that needs to be nailed down. I'm still not convinced that bare filenames is the way to go, but I'm also not convinced that there's a right answer, although there's certainly a lot of wrong answers!
> --
> Steve McConnel
>
> The following message has been appended to this e-mail by JAARS e-mail gateway. Dan Zachary 704-843-6488 JAARS Waxhaw, North Carolina If you believe that this message is a scam or spam, we now have a new technique for detecting them. Samples are welcome. For instructions about how to report samples please see https://mail.jaars.org/~spam_...@sil.org/reportingspam.htm Message from JAARS
> ----WARNING----WARNING----WARNING----
> Zip Files can contain harmful viruses
> SCAM WARNING: There is a current scam involving short messages and attached .zip files. They change hourly, so the anti-virus software does not always keep up with the new variations as quickly as we or you would like. If you were NOT EXPECTING to receive an attached ZIP file, consider it DANGEROUS until you confirm that your friend really did send you a ZIP file. Do NOT open the attached zip file
> unless you know the sender AND are expecting a zip file!
> Contact spam_...@sil.org if
> you have any questions
> --------------------------------------
>
>
>
Ken Zook
In FieldWorks, a user can choose a base directory from which all their picture/media files can live. By default we put pictures in the Pictures subdirectory, and sound/video under the Media subdirectory under this base directory. However, in response to users, the user is allowed to have any directory structure under this base directory to organize their pictures and media files, and they may also reference files anywhere outside this directory if they need to (e.g., a DVD with licensed pictures). So here are some examples where the part in parentheses is what is stored as the picture path in the database.
base directory: c:\FieldWorks
picture: c:\FieldWorks\Pictures\Dictionary\hand.jpg (Pictures\Dictionary\hand.jpg)
picture: c:\FieldWorks\Pictures\NT\priest.jpg (Pictures\NT\priest.jpg)
media: c:\FieldWorks\Media\Dictionary\hand.mp3 (Media\Dictionary\hand.mp3)
picture: d:\Picture Catalog\horse.jpg (d:\Picture Catalog\horse.jpg)
There are various reasons a FieldWorks user will want to use LIFT. One of these is to support transfer to WeSay. WeSay currently has a limited directory structure where all pictures go under Pictures and all media go under Audio. So John has argued for the LIFT picture href to be a file name only without a path. That works for WeSay's limited world view, but will not work for FieldWorks.
Another prime use of LIFT in Flex is to provide a way to pass changes back and forth between remote users working on the same project. To support this we have to provide more information in the LIFT file than what John is requesting. It's easy to strip path information from an href if the application does not need it, but it can't be added if it isn't there. Martin's suggestion comes close to an answer. If we continue to put the relative path stored in FW in the LIFT file, we can reconcile where the files go. Presumably that means that the directory structure under the LIFT directory could map the directory structure under the FieldWorks base directory. If WeSay can handle that, it works well for everything under the base directory. It doesn't solve the situation for files outside the base directory. In this case if we provide a full path and optionally place the picture in the LIFT root directory, we could figure out what to do. If we don't put sufficient information in the href, then we need another field in LIFT to hold the path information FieldWorks needs.
Another use of LIFT is to provide output for Lexique Pro. In this case it would be nice for Lexique Pro to be able to use pictures if they are in the LIFT directory, but if not, it would be nice for Lexique Pro to be able to find the standard picture/media files FieldWorks uses. This is especially true where there may be GBs of media files involved.
Ken
Cambell Prince
Ken Zook wrote:
> We have conflicts that have to be resolved some way.
>
> In FieldWorks, a user can choose a base directory from which all their picture/media files can live. By default we put pictures in the Pictures subdirectory, and sound/video under the Media subdirectory under this base directory. However, in response to users, the user is allowed to have any directory structure under this base directory to organize their pictures and media files, and they may also reference files anywhere outside this directory if they need to (e.g., a DVD with licensed pictures). So here are some examples where the part in parentheses is what is stored as the picture path in the database.
> base directory: c:\FieldWorks
> picture: c:\FieldWorks\Pictures\Dictionary\hand.jpg (Pictures\Dictionary\hand.jpg)
> picture: c:\FieldWorks\Pictures\NT\priest.jpg (Pictures\NT\priest.jpg)
> media: c:\FieldWorks\Media\Dictionary\hand.mp3 (Media\Dictionary\hand.mp3)
> picture: d:\Picture Catalog\horse.jpg (d:\Picture Catalog\horse.jpg)
>
> There are various reasons a FieldWorks user will want to use LIFT. One of these is to support transfer to WeSay. WeSay currently has a limited directory structure where all pictures go under Pictures and all media go under Audio. So John has argued for the LIFT picture href to be a file name only without a path. That works for WeSay's limited world view, but will not work for FieldWorks.
>
>
I'm quite happy with the relative path model. Seems that that would
work fine for WeSay.
How about we have relative paths being relative to the lift file as
preferred, and absolute paths permitted (but likely not practical /
portable). Apps and app authors should discourage the use of absolute
paths.
> Another prime use of LIFT in Flex is to provide a way to pass changes back and forth between remote users working on the same project. To support this we have to provide more information in the LIFT file than what John is requesting. It's easy to strip path information from an href if the application does not need it, but it can't be added if it isn't there. Martin's suggestion comes close to an answer. If we continue to put the relative path stored in FW in the LIFT file, we can reconcile where the files go. Presumably that means that the directory structure under the LIFT directory could map the directory structure under the FieldWorks base directory. If WeSay can handle that, it works well for everything under the base directory. It doesn't solve the situation for files outside the base directory. In this case if we provide a full path and optionally place the picture in the LIFT root directory, we could figure out what to do. If we don't put sufficient information in the href, then we need another field in LIFT to hold the path information FieldWorks needs.
>
> Another use of LIFT is to provide output for Lexique Pro. In this case it would be nice for Lexique Pro to be able to use pictures if they are in the LIFT directory, but if not, it would be nice for Lexique Pro to be able to find the standard picture/media files FieldWorks uses. This is especially true where there may be GBs of media files involved.
>
>
More and more it seems that we need to be heading towards a common
directory structure for this sort of thing. The paths relative to lift
proposal doesn't require it, but it would certainly make it easier to
transfer data around the place if it was common. Especially once we put
Chorus / DVCS in the mix.
Regards,
Cambell
--
Cambell Prince
Payap Language Software and SIL MSEAG
Skype: cambell.prince | Mobile: +66 87 190 5871 | Fax: +64 6 759 6152
www.palaso.org and www.sil.org
Stephen_...@sil.org
Cambell,
Would WeSay be willing to support subdirectory structure inside the pictures and audio folders? The scenario that Ken is talking about is that Flex allows users to carefully build up a folder containing all the pictures (and sound?) files, with a carefully developed arrangement, and then point the FieldWorks "external files directory" to that folder. Adding anything inside that folder as a picture or media file is then stored internally to FieldWorks as a relative path (relative to that selected external folder). But the folder arrangement might well be deeper than just the pictures subfolder and the media (audio) subfolder.
And would the WeSay LIFT file now explicitly say "pictures/something.jpg" instead of "something.jpg"? If so, would WeSay also be willing to support "picturesFromJoe/something.jpg" and "picturesFromSue/something.jpg"?
We need to get portable handling of href values for <illustration> and <media> elements settled quickly if Flex for FW 6.0 is going to be able to "do the right thing". :-)
--
Steve McConnel
| Cambell Prince <cambell...@sil.org>
Sent by: LexiconInter...@googlegroups.com 05/20/2009 10:54 AM
|
|
|
John Hatton
Contrary to what I read in this thread, I've no objection to the href being a relative path to a sub folder.
I am somewhat suspicious of the desirability of having that path point anywhere but the pictures folder (subfolders of that are fine (but why)).
I'm really concerned about any picture paths which point *out* of the lift folder. (e.g. ../../my pictures/foo.jpg). This would seem to be to be setting our users (Wesay and future, collaboration-empowered FLEx users) for failure.
I'm not concerned at all about true "hyperlinks" which point to the web (e.g. http://youtube.com/blah)
JH
Ken Zook
> lift folder. (e.g. ../../my pictures/foo.jpg). This would seem to be
> to be setting our users (Wesay and future, collaboration-empowered FLEx
> users) for failure.
>
I think I'm hearing consensus that the href will store a relative path from the project directory for anything inside the directory, and we encourage that. The user is also able to specify the directory hierarchy inside the project directory for pictures/media, although we will have default locations if they don't specify anything (probably most users). We will also allow a full path to something outside the project directory for special cases. For anything outside the project directory we will make no attempt at copying or relinking the external files.
Ken
Richard
For pictures:
LP looks at relative path, "pictures" sub-folder, and absolute path.
For audio:
LP looks at relative path, "sound", "media" or "audio" sub-folders,
and absolute path.
It handles audio files in writing system forms for lexical-entry and
example fields.
Richard