Dot Porter wrote:
> Using <creation> for this purpose might be fine if you're using the
> Image Markup Tool, but isn't it better to have one single place to
> store software information regardless of whether it content is new or
> old? So whether I use the EPT or the Image Markup Tool (or whatever
> software), there is a standard place to place that information (rather
> than <creation> for IMT and <respStmt> for EPT).

Absolutely. So we either need communal agreement on the right way to do 
this using existing tags, or a new set of tags such as those outlined below.

Incidentally, does the EPT automatically record any information about 
itself in XML documents it creates? If so, what's the info, and how is 
it encoded?


> This is why I initially liked the creation element. It's
>> also unlikely the tool would load general-purpose TEI documents not
>> created with it (although it will load and save into a DocBook format as
>> well as TEI+SVG). It could, however, load files initially created with
>> it, then edited in another application (such as oXygen) as long as the
>> key parts of its structure relating to the image and annotations were
>> not destroyed.
>> Lou Burnard wrote:
>> > Dot's example suggests that we need some special tags for naming
>> > software products e.g. <productName>, <productVersion> etc. which can
>> > appear wherever <name> is permitted.  Wouldn't you want the identifier
>> > for the version within the name, rather than as a sibling of it though?
>> It might be best to begin by setting out the array of information we may
>> want to record with these tags. I've already listed three items:
>>         appName (human-usable application title)
>>         appURI (i.e. where you could go to get the application, or 
>> info about it)
>>         appVersion (conventional dot-separated Major, Minor, Release 
>> and Build
>> integers)
>> I think this may also be very useful:
>>         appId:
>> This would be an identifier for the application which conforms to xml:id
>> constraints. Such ids are used by application developers, for example to
>> create a mutex when an application is running in Windows, so that an
>> installer or uninstaller can check to see whether the application is
>> already running before attempting to install it or uninstall it.
>> We can imagine lots of others, relating to licensing (GPL, Moz 1.1,
>> etc.), registered user, programmer or publisher, but these are less
>> important and more difficult to constrain to a fixed format.
>> I prefer "app" to "product" as a prefix; "product" has a rather nasty
>> marketing-speak flavour about it to me, although that's a personal thing.
>> There is an analogue for all this in the Windows file versioning
>> information system (and presumably on other platforms too). Any Windows
>> executable can contain a data structure which encodes a range of
>> name-value pairs, many of which are formally documented and expected
>> (major version, minor version, build, release, etc.) and some of which
>> are conventional, but it also allows you to add your own name-value
>> pairs and use standard API calls to retrieve them. If we're considering
>> creating a new structure or set of tags, I think it would be a good idea
>> to follow a similar model, with some items we'd expect the application
>> to add to the file, but with the flexibility for other information to be
>> encoded in a standard way. Something like this is what I imagine:
>> <creatorApp>
>>     <appIdent key="appId">ImageMarkupTool1</ident>
>>     <appIdent key="appName">Image Markup Tool</ident>
>>     <appIdent key="appVersion"></appIdent>
>>     <appIdent key="appURI">http://..../</appIdent>
>>     <appIdent key="userDefined" userKey="licence">Mozilla Public Licence
>> 1.1</appIdent>
>>     <date value="2006-05-25T11:03:55">Last save: 2006-05-25 at
>> 11:03:55</date>
>> </creatorApp>
>> With a system like this, getting all the available info about an
>> application is simply a question of iterating through the appIdent tags.
>> specific info can be retrieved using the key attribute (or whatever
>> would be a better name for it). The key attribute could be constrained
>> to an enumeration which also includes "userDefined", and that could be
>> used in combination with an unconstrained userKey attribute to add any
>> info the developer thinks is required.
>> The date tag is useful in this scenario:
>> We can envisage multiple applications working on a file in sequence, and
>> it would be politic not to destroy the creatorApp information about
>> previous applications. For instance, imagine that someone creates a
>> really powerful and intuitive tool for building teiHeaders, and that's
>> all it does. You might mark up an image using the Image Markup Tool
>> (which lets you edit the teiHeader as text, but doesn't help you with
>> it), and then use the teiHeader tool to add an elaborate header. You
>> could then edit the file again in the Image Markup Tool (which wouldn't
>> damage or change any elements of the teiHeader other than those which
>> directly concern it). It would be important to know which of these
>> applications was used to edit the file, and when. So each tool, assuming
>> they're both using this proposed versioning system, would be able to
>> identify its own creatorApp tag (using the appId) and modify that every
>> time it edited the file, while leaving the other application's
>> creatorApp tag alone.
>> Does this make sense?
>> I really don't want to customize my schemas to add support for this
>> information; it really is useless if it can't be found in a predictable
>> location in a reliable format, because the whole idea is that it be read
>> and written automatically by authoring programs.
>> Cheers,
>> Martin
>> >
>> >
>> > Dot Porter wrote:
>> >> Peter, you're correct - the image descriptions that Martin's tool
>> >> creates could be either completely new texts, or transcripts of
>> >> existing texts. Does it make sense to use <respStmt> to note the
>> >> software and <creation> to note the "newness" of the descriptions? I'm
>> >> just not comfortable using <creation> to note the software.
>> >>
>> >> <respStmt>
>> >>  <resp>encoded using</resp>
>> >>  <name>Image Markup Tool</name>
>> >>  <ident></ident>
>> >> <respStmt>
>> >> <respStmt>
>> >>   <resp>encoded by</resp>
>> >>   <name>Dot Porter</name>
>> >> </respStmt>
>> >>
>> >> and, if the image descriptions are new:
>> >>
>> >> <profileDesc>
>> >>   <creation>
>> >>     Image descriptions by Dot Porter.
>> >>   </creation>
>> >> </profileDesc>
>> >>
>> >> Dot
>> >>
>> >> On 5/25/06, Peter Boot <[log in to unmask]> wrote:
>> >>
>> >>> Dot Porter wrote:
>> >>>
>> >>>
>> >>>> Martin, I agree with Lou; from the description in the guidelines it
>> >>>> looks like <creation> is specifically to describe the source text.
>> >>>
>> >>> If I remember rightly, the TEI text that Martin's tool creates is not
>> >>> (necessarily) the transcription of an old text. It might as well be a
>> >>> new, editorial text about an image fragment. The editor, using the 
>> tool,
>> >>> creates a new text. It would seem to me therefore that the creation
>> >>> element is appropriate.
>> >>>
>> >>> Peter
>> >>>
>> >>
>> >>
>> >>
>> >
>> -- 
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> ([log in to unmask])
>> Half-Baked Software, Inc.
>> ([log in to unmask])
>> [log in to unmask]

Martin Holmes
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]