[osis-core] <resp>

[Todd Tillinghast]

Patrick,

My concern is that if we were to add a new element that we should
consider the need for the companion elements in the header.  If we are
not adding an element then the user manual approach should work fine for
now.

Todd

> -----Original Message-----
> From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> Sent: Wednesday, October 01, 2003 8:07 AM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] <resp>
> 
> Todd,
> 
> I am not sure this would be in the current user's manual or in a
> supplemental technical manual. Not likely to be encountered by the
> average user.
> 
> My suggestion would be as a "best practice" to put the encoding
> practices in the header under <description>. There one can define what
> regex is found in "resp" for example, the one I listed being only a
> suggested form. There could be others. Not very likely to be able to
> automatically extract encoding practices from a description so I don't
> see any harm in having it in free text.
> 
> Hope you are having a great day!
> 
> Patrick
> 
> Todd Tillinghast wrote:
> > Does the including of "who" and "what" lead to a need to define
> > somewhere (likely in the header) what is meant by "who" and "what"?
> >
> > If I put DTT (my initials) for the "who" we need some place to
define
> > who is "DTT".  Same thing for "what".
> >
> > Todd
> >
> >
> >>-----Original Message-----
> >>From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> >>admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> >>Sent: Tuesday, September 30, 2003 5:03 AM
> >>To: osis-core@bibletechnologieswg.org
> >>Subject: Re: [osis-core] <resp>
> >>
> >>Chris,
> >>
> >>I talked to Troy late yesterday (my time anyway) about this issue.
> >>
> >>As I understand his example, he wants to record what (Strong's
> >
> > numbers)
> >
> >>were entered by who (person) and the date of entry, along wtih the
who
> >>(person) proofed (correction/approval of Strong's numbers) and the
> >
> > date.
> >
> >>Since this is production information that will not appear in a
public
> >>version of the text, or well, need not appear, I suggested creating
an
> >>extension to the schema to allow an element to hold this
information.
> >>After reading your post, there really isn't any reason to not use
the
> >>resp attribute, albeit with a little more complex structure than one
> >>associates with attribute values.
> >>
> >>At first blush I would suggest:
> >>
> >>(((yyyy-mm-dd|who|what)|)?)*
> >>
> >>being required in prose and prohibiting the separator "|" (also in
> >>prose) from appearing in the "who" or "what" portions of the
> >
> > expression.
> >
> >>Semantics: applies to the specified "what" inside the element which
> >>bears the resp attribute.
> >>
> >>Suggest that the "what" be fairly specific, Troy's Strong Numbers is
a
> >>good example. Not much doubt about what was added or proofed.
> >>
> >>Note that you could have any number of dates, whos and whats in the
> >>string, perhaps addressing different "whats" inside the container.
> >>
> >>I talked to Todd yesterday and I think we may need to have a
separate
> >>technical manual that goes beyond the users manual now under
> >>construction. I can't imagine this being of interest to anyone hand
> >>coding texts but would be of interest in production environments.
> >>
> >>Does the solution for resp work for everybody?
> >>
> >>Thoughts on having a separate technical manual?
> >>
> >>Hope everyone is at the start of a great day!
> >>
> >>Patrick
> >>
> >>Chris Little wrote:
> >>
> >>>Okay... Troy pointed out to me we already have a resp attribute in
> >>>globalWith/WithoutType and that it is xs:string.  But he points out
> >>
> > that
> >
> >>>he doesn't "know how to use it to encode all the information
needed:
> >>
> > who
> >
> >>>/ what / when," which points to the need for a best practice
> >>
> > statement
> >
> >>>for the manual, if not constraint via a pattern.
> >>>
> >>>Given that it's already implemented as xs:string, I'm sure the best
> >>>practice route will be preferrable, though we can probably be
fairly
> >>>confident that no one has actually used the resp attribute to date
> >>
> > in
> >
> >>>any documents.
> >>>
> >>>--Chris
> >>>
> >>>Chris Little wrote:
> >>>
> >>>
> >>>>Hmm, I find myself in the rather diagreeable position of agreeing
> >>>
> > with
> >
> >>>>Troy. :)
> >>>>
> >>>>I'm not sure that he isn't thinking of the resp attribute on
> >>>>revisionDesc, but I think the availability of resp in any location
> >>>>would be invaluable for translation & linguistic annotation (the
> >>>>latter actually being what Troy is using it for here).
> >>>>
> >>>>I would argue that it would be better if we could stick it into an
> >>>>attribute that would be better, though, since it is essentially
> >>>>information about a container (I assume).
> >>>>
> >>>>TEI's version is here:
> >>>
> > http://www.tei-c.org/Vault/GL/P3/ref/RESP.htm .
> >
> >>>>I would suggest something like adding resp to
> >>>
> > globalWith/WithoutType
> >
> >>>>as type xs:string.  Or with a pattern that allows encoding name,
> >>>
> > date,
> >
> >>>>& comment, like Troy's example (e.g. "[A-Za-z0-9
> >>>>
> >>>
> >
]+(\|([0-9]{4}\-[0-9]{2}\-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2})?\|[A-Za-
> >
> >>z0-9
> >>
> >>>>\-\:]+)?", using pipe as field divider).
> >>>>
> >>>>--Chris
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>osis-core mailing list
> >>>osis-core@bibletechnologieswg.org
> >>>http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> >>>
> >>
> >>
> >>--
> >>Patrick Durusau
> >>Director of Research and Development
> >>Society of Biblical Literature
> >>Patrick.Durusau@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!
> >>
> >>
> >>_______________________________________________
> >>osis-core mailing list
> >>osis-core@bibletechnologieswg.org
> >>http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> >
> >
> > _______________________________________________
> > osis-core mailing list
> > osis-core@bibletechnologieswg.org
> > http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> >
> 
> 
> --
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> Patrick.Durusau@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!
> 
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core