[osis-core] Copyright, Rights, etc.
Patrick Durusau
Patrick.Durusau at sbl-site.org
Wed Oct 27 10:45:04 MST 2004
Jim,
Cutting to copyright, rights, etc.:
Jim_Albright at wycliffe.org wrote:
Ah, so we are not talking about encoding extant printed texts but
preparing material for printing? OK, that is a horse of a different color!
Even more reason to not statically encode the copyright page. Why would
you? All the information should be in the header, well, at least a
properly prepared one.
What happens if you change the formatting or have to take an image out?
Well the page breaks shift and you have to print it out (or at least to
screen) and re-enter all the location information for images listed on
the copyright page.
If on the other hand, you draw all the information from the header and
automatically construct the copyright page, then it doesn't matter if
the format changes, material is taken out or inserted, etc. (I have
actually done this in both DSSSL and XSLT so I know it works.)
There really isn't any reason to create a static page when what you want
is available by processing the header.
That would be like creating a static table of contents page. Sure, we
provide for encoding one, should one exist because what I generate may
not be faithful to the original printed version but that is different
than encoding one for a new text about to be printed.
Does that work?
Hope you are having a great day!
Patrick
>
> Copyright_Statement: Covered under rights in the header. This is the
> standard location in Dublin Core. Don't think we gain anything by adding
> another potential location for the information.
>
>>>>>>>>>I see the need for three groups of things on the Copyright Page
>>>>>>>>>this is still under development in TE
>>>>>>>>>But for formatting the copyright page the three units are
>>>>>>>>>Credits, Rights, and Copyright Statement ... with a possible code
>>>>>>>>
> for internal control (SIL adds the job code here)
>
>>>>>>see note on Rights below
>>>>>
>
> Unless you mean to say that the copyright page as an artifact needs to
> be encoded. I suspect we could add a type to div but to be honest, I
> don't see the point. Just make it a div and if you need copyright
> information, get it from the header.
>
>>>>>Yes I want div type="copyrightPage"
>>>>
> Credits: Same here, I could counsel just paragraphs with the usual
> sub-elements. Don't gain anything if you have properly prepared the
> header which has the very long enumeration of roles for credit, etc. I
> guess in part I don't see any reason to privilege a poor retelling of
> information already presented in a useful fashion in the header.
>
>>>>>>>credits require the page number for each use ... so David C. Cook
>>>>>>
> lets us use pictures found on page x,x,x,x,x .... which may need to be
> added by hand ... also sometimes the info in header is in English but in
> Credits it will be in national language.
>
>
>
>
> Not saying people should not enter it, but it is just an artifact of
> printing and not something you will need to identify later for
> processing. For those purposes, use the header information.
>
>>>>>>Printing is our main goal so it is much more than an artifact
>>>>>
>
<snip>
>
> Rights: In terms of accessible information, handled by Dublin Core
> element in header. Is there some reason to duplicate here?
>
>>>>>>may be enough here for content but
>>>>>><p type="credits">
>>>>>><p type="rights">
>>>>>><p type="copyrightStatement">
>>>>>>would really help for formatting
>>>>>
>
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau at sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Topic Maps: Human, not artificial, intelligence at work!
More information about the osis-core
mailing list