Encoding status of items rather than documents

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Encoding status of items rather than documents

Martin Holmes
Hi all,

I think we're all familiar with the @status attribute in att.docStatus:

<https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>

which allows us to record "the status of a document either currently or,
when associated with a dated element, at the time indicated," with
sample values including "draft", "candidate", "published", and so on.
 From its name and definition, it's presumably intended to apply to an
entire document (although it's also available on <bibl>, <object> and
some other elements which are presumably held to constitute
document-level units).

We have an increasing need to track the status (draft, proofed,
published and so on) not of entire documents but of individual items in
resource lists, such as:

<person>
<entry>/<entryFree>
<place>
<bibl> (already has @docStatus, but is it appropriate for this?)
<item>

The use-case is, for example: We have a large personography which is
constantly being added to and edited. New empty <person> entries are
added ("proposed"); content of items is drafted ("draft"); then they are
proofed, approved, published and so on; and occasionally they are
deprecated and withdrawn. Across the personography, individual entries
are always at different stages in this process.

How have other TEI projects handled this? It would be really handy for
us to have @status available on these entity elements, but there may be
effective ways to use existing elements or attributes that we haven't
thought of.

All help appreciated,
Martin
--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Martin de la Iglesia-3
Hi Martin,
The solution I use is simply

<note type="status">draft</note>



— 
Martin de la Iglesia
Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen Philipp Hainhofers (1578-1647)
Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel     Tel. +49 5331 808-125



Von: Martin Holmes <[hidden email]>
An: <[hidden email]>
Gesendet: 09.07.2020 17:54
Betreff: Encoding status of items rather than documents

Hi all,

I think we're all familiar with the @status attribute in att.docStatus:

<https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>

which allows us to record "the status of a document either currently or,
when associated with a dated element, at the time indicated," with
sample values including "draft", "candidate", "published", and so on.
From its name and definition, it's presumably intended to apply to an
entire document (although it's also available on <bibl>, <object> and
some other elements which are presumably held to constitute
document-level units).

We have an increasing need to track the status (draft, proofed,
published and so on) not of entire documents but of individual items in
resource lists, such as:

<person>
<entry>/<entryFree>
<place>
<bibl> (already has @docStatus, but is it appropriate for this?)
<item>

The use-case is, for example: We have a large personography which is
constantly being added to and edited. New empty <person> entries are
added ("proposed"); content of items is drafted ("draft"); then they are
proofed, approved, published and so on; and occasionally they are
deprecated and withdrawn. Across the personography, individual entries
are always at different stages in this process.

How have other TEI projects handled this? It would be really handy for
us to have @status available on these entity elements, but there may be
effective ways to use existing elements or attributes that we haven't
thought of.

All help appreciated,
Martin
--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Martin Holmes
Hi Martin,

That'll work, but it's a bit less elegant than an attribute. Only
Schematron can constrain the content of <note> with this solution
(assuming <note> is used for any other purpose, which it surely is), so
you don't get the benefit of schema-based prompting for encoders; and
it's expressing a property of the parent element through the content of
a child, which is not ideal.

Cheers,
Martin

On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:

> Hi Martin,
> The solution I use is simply
>
> <note type="status">draft</note>
>
>
>
> —
> Martin de la Iglesia
> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
> Philipp Hainhofers (1578-1647)
> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel     Tel.
> +49 5331 808-125
>
>
>
> *Von: * Martin Holmes <[hidden email]>
> *An: * <[hidden email]>
> *Gesendet: * 09.07.2020 17:54
> *Betreff: * Encoding status of items rather than documents
>
>     Hi all,
>
>     I think we're all familiar with the @status attribute in att.docStatus:
>
>     <https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>
>
>
>     which allows us to record "the status of a document either currently
>     or,
>     when associated with a dated element, at the time indicated," with
>     sample values including "draft", "candidate", "published", and so on.
>      From its name and definition, it's presumably intended to apply to an
>     entire document (although it's also available on <bibl>, <object> and
>     some other elements which are presumably held to constitute
>     document-level units).
>
>     We have an increasing need to track the status (draft, proofed,
>     published and so on) not of entire documents but of individual items in
>     resource lists, such as:
>
>     <person>
>     <entry>/<entryFree>
>     <place>
>     <bibl> (already has @docStatus, but is it appropriate for this?)
>     <item>
>
>     The use-case is, for example: We have a large personography which is
>     constantly being added to and edited. New empty <person> entries are
>     added ("proposed"); content of items is drafted ("draft"); then they
>     are
>     proofed, approved, published and so on; and occasionally they are
>     deprecated and withdrawn. Across the personography, individual entries
>     are always at different stages in this process.
>
>     How have other TEI projects handled this? It would be really handy for
>     us to have @status available on these entity elements, but there may be
>     effective ways to use existing elements or attributes that we haven't
>     thought of.
>
>     All help appreciated,
>     Martin
>     --
>     -------------------------------------
>     Humanities Computing and Media Centre
>     University of Victoria
>     [hidden email]
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Martin de la Iglesia-3
I'm afraid I don't really get either of your points:


That'll work, but it's a bit less elegant than an attribute. Only
Schematron can constrain the content of <note> with this solution
(assuming <note> is used for any other purpose, which it surely is), so
you don't get the benefit of schema-based prompting for encoders; and

To prompt encoders, I set up a checkbox in Oxygen author mode that sets the <note> content.



it's expressing a property of the parent element through the content of
a child, which is not ideal.

Why not? That's the way e.g. RDF/XML works too.


Martin


— 
Martin de la Iglesia
Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen Philipp Hainhofers (1578-1647)
Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel     Tel. +49 5331 808-125



Von: Martin Holmes <[hidden email]>
An: Martin de la Iglesia <[hidden email]>, <[hidden email]>
Gesendet: 09.07.2020 18:07
Betreff: Re: Encoding status of items rather than documents

Hi Martin,

That'll work, but it's a bit less elegant than an attribute. Only
Schematron can constrain the content of <note> with this solution
(assuming <note> is used for any other purpose, which it surely is), so
you don't get the benefit of schema-based prompting for encoders; and
it's expressing a property of the parent element through the content of
a child, which is not ideal.

Cheers,
Martin

On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:

> Hi Martin,
> The solution I use is simply
>
> <note type="status">draft</note>
>
>
>
> —
> Martin de la Iglesia
> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
> Philipp Hainhofers (1578-1647)
> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel     Tel.
> +49 5331 808-125
>
>
>
> *Von: * Martin Holmes <[hidden email]>
> *An: * <[hidden email]>
> *Gesendet: * 09.07.2020 17:54
> *Betreff: * Encoding status of items rather than documents
>
>     Hi all,
>
>     I think we're all familiar with the @status attribute in att.docStatus:
>
>     <https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>
>
>
>     which allows us to record "the status of a document either currently
>     or,
>     when associated with a dated element, at the time indicated," with
>     sample values including "draft", "candidate", "published", and so on.
>      From its name and definition, it's presumably intended to apply to an
>     entire document (although it's also available on <bibl>, <object> and
>     some other elements which are presumably held to constitute
>     document-level units).
>
>     We have an increasing need to track the status (draft, proofed,
>     published and so on) not of entire documents but of individual items in
>     resource lists, such as:
>
>     <person>
>     <entry>/<entryFree>
>     <place>
>     <bibl> (already has @docStatus, but is it appropriate for this?)
>     <item>
>
>     The use-case is, for example: We have a large personography which is
>     constantly being added to and edited. New empty <person> entries are
>     added ("proposed"); content of items is drafted ("draft"); then they
>     are
>     proofed, approved, published and so on; and occasionally they are
>     deprecated and withdrawn. Across the personography, individual entries
>     are always at different stages in this process.
>
>     How have other TEI projects handled this? It would be really handy for
>     us to have @status available on these entity elements, but there may be
>     effective ways to use existing elements or attributes that we haven't
>     thought of.
>
>     All help appreciated,
>     Martin
>     --
>     -------------------------------------
>     Humanities Computing and Media Centre
>     University of Victoria
>     [hidden email]
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Martin Holmes
Hi Martin,

On 2020-07-09 9:23 a.m., Martin de la Iglesia wrote:

> I'm afraid I don't really get either of your points:
>
>
>     That'll work, but it's a bit less elegant than an attribute. Only
>     Schematron can constrain the content of <note> with this solution
>     (assuming <note> is used for any other purpose, which it surely is), so
>     you don't get the benefit of schema-based prompting for encoders; and
>
>
> To prompt encoders, I set up a checkbox in Oxygen author mode that sets
> the <note> content.

We don't usually use Author Mode, so that wouldn't work for us.

>     it's expressing a property of the parent element through the content of
>     a child, which is not ideal.
>
> Why not? That's the way e.g. RDF/XML works too.

It seems inelegant to me. I think I'd prefer a custom attribute class,
to which we could add those elements that need it.

Cheers,
Martin

>
>
> Martin
>
>
> —
> Martin de la Iglesia
> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
> Philipp Hainhofers (1578-1647)
> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel     Tel.
> +49 5331 808-125
>
>
>
> *Von: * Martin Holmes <[hidden email]>
> *An: * Martin de la Iglesia <[hidden email]>, <[hidden email]>
> *Gesendet: * 09.07.2020 18:07
> *Betreff: * Re: Encoding status of items rather than documents
>
>     Hi Martin,
>
>     That'll work, but it's a bit less elegant than an attribute. Only
>     Schematron can constrain the content of <note> with this solution
>     (assuming <note> is used for any other purpose, which it surely is), so
>     you don't get the benefit of schema-based prompting for encoders; and
>     it's expressing a property of the parent element through the content of
>     a child, which is not ideal.
>
>     Cheers,
>     Martin
>
>     On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:
>      > Hi Martin,
>      > The solution I use is simply
>      >
>      > <note type="status">draft</note>
>      >
>      >
>      >
>      > —
>      > Martin de la Iglesia
>      > Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
>      > Philipp Hainhofers (1578-1647)
>      > Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel    
>     Tel.
>      > +49 5331 808-125
>      >
>      >
>      >
>      > *Von: * Martin Holmes <[hidden email]>
>      > *An: * <[hidden email]>
>      > *Gesendet: * 09.07.2020 17:54
>      > *Betreff: * Encoding status of items rather than documents
>      >
>      >     Hi all,
>      >
>      >     I think we're all familiar with the @status attribute in
>     att.docStatus:
>      >
>      >    
>     <https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>
>
>      >
>      >
>      >     which allows us to record "the status of a document either
>     currently
>      >     or,
>      >     when associated with a dated element, at the time indicated,"
>     with
>      >     sample values including "draft", "candidate", "published",
>     and so on.
>      >      From its name and definition, it's presumably intended to
>     apply to an
>      >     entire document (although it's also available on <bibl>,
>     <object> and
>      >     some other elements which are presumably held to constitute
>      >     document-level units).
>      >
>      >     We have an increasing need to track the status (draft, proofed,
>      >     published and so on) not of entire documents but of
>     individual items in
>      >     resource lists, such as:
>      >
>      >     <person>
>      >     <entry>/<entryFree>
>      >     <place>
>      >     <bibl> (already has @docStatus, but is it appropriate for this?)
>      >     <item>
>      >
>      >     The use-case is, for example: We have a large personography
>     which is
>      >     constantly being added to and edited. New empty <person>
>     entries are
>      >     added ("proposed"); content of items is drafted ("draft");
>     then they
>      >     are
>      >     proofed, approved, published and so on; and occasionally they
>     are
>      >     deprecated and withdrawn. Across the personography,
>     individual entries
>      >     are always at different stages in this process.
>      >
>      >     How have other TEI projects handled this? It would be really
>     handy for
>      >     us to have @status available on these entity elements, but
>     there may be
>      >     effective ways to use existing elements or attributes that we
>     haven't
>      >     thought of.
>      >
>      >     All help appreciated,
>      >     Martin
>      >     --
>      >     -------------------------------------
>      >     Humanities Computing and Media Centre
>      >     University of Victoria
>      >     [hidden email]
>      >
>
>     --
>     -------------------------------------
>     Humanities Computing and Media Centre
>     University of Victoria
>     [hidden email]
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Paul Schaffner
In reply to this post by Martin de la Iglesia-3
Since I use neither of these, but instead rely on some homemade attributes
to record states of revision, I should say nothing. But when has that
stopped me? So, two suggestions:

1. @resp.
Since @resp can appear on any likely content-bearing element, and can
point to either specific or generic responsibility statements, wouldn't
it be possible to reconceptualize the 'status' of your components as being
the result of activity of a particular sort of contributor, whether or
not you choose to associate it also with a particular person? e.g., an
entry might have a @resp pointing to a generic editor, a reviser, a drafter,
a finisher, or even a deleter, with the status to be inferred from the
nature of the activity. I.e. use @resp="drafter" in place of @status="drafted".

2. @change
It would probably be an abusive stretch to re-purpose the genetic editing/transcription
attribute @change along the same lines, though the model appears robust
enough to support whatever subtleties of revision you like, without
breaking the letter of the law.

[My own approach is probably the reverse of intuitive, since
it relies on a set of codes for various activities which might
be applied to a proposed addition, say "R[eview]" "I[ntegrate]"
"E[xpand]" etc. ... When the addition is created, the creator
supplies an attribute listing all the things that still need to
be done to it, as in todo="R I E"; when each step is completed,
in whatever order, the appropriate code is removed. This allows me
to easily find all the additions that still need review, improvement,
integration, approval, etc.]

pfs

On Thu, Jul 9, 2020, at 12:23, Martin de la Iglesia wrote:

> I'm afraid I don't really get either of your points:
>
> >
> > That'll work, but it's a bit less elegant than an attribute. Only
> > Schematron can constrain the content of <note> with this solution
> > (assuming <note> is used for any other purpose, which it surely is), so
> > you don't get the benefit of schema-based prompting for encoders; and
>
> To prompt encoders, I set up a checkbox in Oxygen author mode that sets
> the <note> content.
>
>
> >
> > it's expressing a property of the parent element through the content of
> > a child, which is not ideal.
>
> Why not? That's the way e.g. RDF/XML works too.
>
>
> Martin
>
>
> —
> Martin de la Iglesia
> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
> Philipp Hainhofers (1578-1647)
> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel. +49
> 5331 808-125
>
>
>
> * Von: * Martin Holmes <[hidden email]>
> * An: * Martin de la Iglesia <[hidden email]>, <[hidden email]>
> * Gesendet: * 09.07.2020 18:07
> * Betreff: * Re: Encoding status of items rather than documents
>
> > Hi Martin,
> >
> > That'll work, but it's a bit less elegant than an attribute. Only
> > Schematron can constrain the content of <note> with this solution
> > (assuming <note> is used for any other purpose, which it surely is), so
> > you don't get the benefit of schema-based prompting for encoders; and
> > it's expressing a property of the parent element through the content of
> > a child, which is not ideal.
> >
> > Cheers,
> > Martin
> >
> > On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:
> > > Hi Martin,
> > > The solution I use is simply
> > >
> > > <note type="status">draft</note>
> > >
> > >
> > >
> > > —
> > > Martin de la Iglesia
> > > Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
> > > Philipp Hainhofers (1578-1647)
> > > Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel.
> > > +49 5331 808-125
> > >
> > >
> > >
> > > *Von: * Martin Holmes <[hidden email]>
> > > *An: * <[hidden email]>
> > > *Gesendet: * 09.07.2020 17:54
> > > *Betreff: * Encoding status of items rather than documents
> > >
> > > Hi all,
> > >
> > > I think we're all familiar with the @status attribute in att.docStatus:
> > >
> > > <https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>
> > >
> > >
> > > which allows us to record "the status of a document either currently
> > > or,
> > > when associated with a dated element, at the time indicated," with
> > > sample values including "draft", "candidate", "published", and so on.
> > > From its name and definition, it's presumably intended to apply to an
> > > entire document (although it's also available on <bibl>, <object> and
> > > some other elements which are presumably held to constitute
> > > document-level units).
> > >
> > > We have an increasing need to track the status (draft, proofed,
> > > published and so on) not of entire documents but of individual items in
> > > resource lists, such as:
> > >
> > > <person>
> > > <entry>/<entryFree>
> > > <place>
> > > <bibl> (already has @docStatus, but is it appropriate for this?)
> > > <item>
> > >
> > > The use-case is, for example: We have a large personography which is
> > > constantly being added to and edited. New empty <person> entries are
> > > added ("proposed"); content of items is drafted ("draft"); then they
> > > are
> > > proofed, approved, published and so on; and occasionally they are
> > > deprecated and withdrawn. Across the personography, individual entries
> > > are always at different stages in this process.
> > >
> > > How have other TEI projects handled this? It would be really handy for
> > > us to have @status available on these entity elements, but there may be
> > > effective ways to use existing elements or attributes that we haven't
> > > thought of.
> > >
> > > All help appreciated,
> > > Martin
> > > --
> > > -------------------------------------
> > > Humanities Computing and Media Centre
> > > University of Victoria
> > > [hidden email]
> > >
> >
> > --
> > -------------------------------------
> > Humanities Computing and Media Centre
> > University of Victoria
> > [hidden email]

--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Laurent Romary
I have been (probably abusively) using @status extensively by  applying  att.docStatus to quite a few elements in one of my favourite customization.
To indicate that a decision concerning a content, e.g. designation of a place where a given document would be applicable, is not yet completely made, or that some information has been extracted automatically from a document (using GROBID) as opposed to being manually set etc.
I  guess we could easily create a general purpose att.contentStatus class and have it available for customization (or make it global?)
Cheers,
Laurent


Le 10 juil. 2020 à 06:01, Paul Schaffner <[hidden email]> a écrit :

Since I use neither of these, but instead rely on some homemade attributes
to record states of revision, I should say nothing. But when has that
stopped me? So, two suggestions:

1. @resp.
Since @resp can appear on any likely content-bearing element, and can
point to either specific or generic responsibility statements, wouldn't
it be possible to reconceptualize the 'status' of your components as being
the result of activity of a particular sort of contributor, whether or
not you choose to associate it also with a particular person? e.g., an
entry might have a @resp pointing to a generic editor, a reviser, a drafter,
a finisher, or even a deleter, with the status to be inferred from the
nature of the activity. I.e. use @resp="drafter" in place of @status="drafted".

2. @change
It would probably be an abusive stretch to re-purpose the genetic editing/transcription
attribute @change along the same lines, though the model appears robust
enough to support whatever subtleties of revision you like, without
breaking the letter of the law.

[My own approach is probably the reverse of intuitive, since
it relies on a set of codes for various activities which might
be applied to a proposed addition, say "R[eview]" "I[ntegrate]"
"E[xpand]" etc. ... When the addition is created, the creator
supplies an attribute listing all the things that still need to
be done to it, as in todo="R I E"; when each step is completed,
in whatever order, the appropriate code is removed. This allows me
to easily find all the additions that still need review, improvement,
integration, approval, etc.]

pfs

On Thu, Jul 9, 2020, at 12:23, Martin de la Iglesia wrote:
I'm afraid I don't really get either of your points:


That'll work, but it's a bit less elegant than an attribute. Only
Schematron can constrain the content of <note> with this solution
(assuming <note> is used for any other purpose, which it surely is), so
you don't get the benefit of schema-based prompting for encoders; and

To prompt encoders, I set up a checkbox in Oxygen author mode that sets
the <note> content.



it's expressing a property of the parent element through the content of
a child, which is not ideal.

Why not? That's the way e.g. RDF/XML works too.


Martin



Martin de la Iglesia
Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
Philipp Hainhofers (1578-1647)
Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel. +49
5331 808-125



* Von: * Martin Holmes <[hidden email]>
* An: * Martin de la Iglesia <[hidden email]>, <[hidden email]>
* Gesendet: * 09.07.2020 18:07
* Betreff: * Re: Encoding status of items rather than documents

Hi Martin,

That'll work, but it's a bit less elegant than an attribute. Only
Schematron can constrain the content of <note> with this solution
(assuming <note> is used for any other purpose, which it surely is), so
you don't get the benefit of schema-based prompting for encoders; and
it's expressing a property of the parent element through the content of
a child, which is not ideal.

Cheers,
Martin

On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:
Hi Martin,
The solution I use is simply

<note type="status">draft</note>




Martin de la Iglesia
Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
Philipp Hainhofers (1578-1647)
Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel.
+49 5331 808-125



*Von: * Martin Holmes <[hidden email]>
*An: * <[hidden email]>
*Gesendet: * 09.07.2020 17:54
*Betreff: * Encoding status of items rather than documents

Hi all,

I think we're all familiar with the @status attribute in att.docStatus:

<https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>


which allows us to record "the status of a document either currently
or,
when associated with a dated element, at the time indicated," with
sample values including "draft", "candidate", "published", and so on.
From its name and definition, it's presumably intended to apply to an
entire document (although it's also available on <bibl>, <object> and
some other elements which are presumably held to constitute
document-level units).

We have an increasing need to track the status (draft, proofed,
published and so on) not of entire documents but of individual items in
resource lists, such as:

<person>
<entry>/<entryFree>
<place>
<bibl> (already has @docStatus, but is it appropriate for this?)
<item>

The use-case is, for example: We have a large personography which is
constantly being added to and edited. New empty <person> entries are
added ("proposed"); content of items is drafted ("draft"); then they
are
proofed, approved, published and so on; and occasionally they are
deprecated and withdrawn. Across the personography, individual entries
are always at different stages in this process.

How have other TEI projects handled this? It would be really handy for
us to have @status available on these entity elements, but there may be
effective ways to use existing elements or attributes that we haven't
thought of.

All help appreciated,
Martin
--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]


--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]

--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/

Laurent Romary
Inria, team ALMAnaCH






Reply | Threaded
Open this post in threaded view
|

Re: Encoding status of items rather than documents

Martin Holmes
In reply to this post by Paul Schaffner
Hi Paul and Laurent,

@resp is a possibility, and I have used it in a similar way, pointing to
a respStmt in which the resp is "proofer" or "editor". It adds a little
to the complexity of the process, and it would add a processing step
(instead of reading an attribute value on each of 4,000 person entries,
you'd be reading an attribute value, looking up a <respStmt>, then
looking at its <resp> to find the item status). I agree with you about
@change; that would be tag abuse.

On balance, I'm with Laurent; I think the simplicity and clarity of
@status on the element itself wins for me. I think many projects might
use this, so in addition to creating a customization for the moment,
I'll raise a feature request, unless anyone can think of a strong objection.

I wonder if we could just extend att.docStatus and reinterpret its name
to mean "document the status of..."?

Cheers,
Martin

On 2020-07-09 9:01 p.m., Paul Schaffner wrote:

> Since I use neither of these, but instead rely on some homemade attributes
> to record states of revision, I should say nothing. But when has that
> stopped me? So, two suggestions:
>
> 1. @resp.
> Since @resp can appear on any likely content-bearing element, and can
> point to either specific or generic responsibility statements, wouldn't
> it be possible to reconceptualize the 'status' of your components as being
> the result of activity of a particular sort of contributor, whether or
> not you choose to associate it also with a particular person? e.g., an
> entry might have a @resp pointing to a generic editor, a reviser, a drafter,
> a finisher, or even a deleter, with the status to be inferred from the
> nature of the activity. I.e. use @resp="drafter" in place of @status="drafted".
>
> 2. @change
> It would probably be an abusive stretch to re-purpose the genetic editing/transcription
> attribute @change along the same lines, though the model appears robust
> enough to support whatever subtleties of revision you like, without
> breaking the letter of the law.
>
> [My own approach is probably the reverse of intuitive, since
> it relies on a set of codes for various activities which might
> be applied to a proposed addition, say "R[eview]" "I[ntegrate]"
> "E[xpand]" etc. ... When the addition is created, the creator
> supplies an attribute listing all the things that still need to
> be done to it, as in todo="R I E"; when each step is completed,
> in whatever order, the appropriate code is removed. This allows me
> to easily find all the additions that still need review, improvement,
> integration, approval, etc.]
>
> pfs
>
> On Thu, Jul 9, 2020, at 12:23, Martin de la Iglesia wrote:
>> I'm afraid I don't really get either of your points:
>>
>>>
>>> That'll work, but it's a bit less elegant than an attribute. Only
>>> Schematron can constrain the content of <note> with this solution
>>> (assuming <note> is used for any other purpose, which it surely is), so
>>> you don't get the benefit of schema-based prompting for encoders; and
>>
>> To prompt encoders, I set up a checkbox in Oxygen author mode that sets
>> the <note> content.
>>
>>
>>>
>>> it's expressing a property of the parent element through the content of
>>> a child, which is not ideal.
>>
>> Why not? That's the way e.g. RDF/XML works too.
>>
>>
>> Martin
>>
>>
>> —
>> Martin de la Iglesia
>> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
>> Philipp Hainhofers (1578-1647)
>> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel. +49
>> 5331 808-125
>>
>>
>>
>> * Von: * Martin Holmes <[hidden email]>
>> * An: * Martin de la Iglesia <[hidden email]>, <[hidden email]>
>> * Gesendet: * 09.07.2020 18:07
>> * Betreff: * Re: Encoding status of items rather than documents
>>
>>> Hi Martin,
>>>
>>> That'll work, but it's a bit less elegant than an attribute. Only
>>> Schematron can constrain the content of <note> with this solution
>>> (assuming <note> is used for any other purpose, which it surely is), so
>>> you don't get the benefit of schema-based prompting for encoders; and
>>> it's expressing a property of the parent element through the content of
>>> a child, which is not ideal.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 2020-07-09 9:00 a.m., Martin de la Iglesia wrote:
>>>> Hi Martin,
>>>> The solution I use is simply
>>>>
>>>> <note type="status">draft</note>
>>>>
>>>>
>>>>
>>>> —
>>>> Martin de la Iglesia
>>>> Kommentierte digitale Edition der Reise- und Sammlungsbeschreibungen
>>>> Philipp Hainhofers (1578-1647)
>>>> Herzog August Bibliothek, Lessingplatz 1, 38304 Wolfenbüttel Tel.
>>>> +49 5331 808-125
>>>>
>>>>
>>>>
>>>> *Von: * Martin Holmes <[hidden email]>
>>>> *An: * <[hidden email]>
>>>> *Gesendet: * 09.07.2020 17:54
>>>> *Betreff: * Encoding status of items rather than documents
>>>>
>>>> Hi all,
>>>>
>>>> I think we're all familiar with the @status attribute in att.docStatus:
>>>>
>>>> <https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.docStatus.html>
>>>>
>>>>
>>>> which allows us to record "the status of a document either currently
>>>> or,
>>>> when associated with a dated element, at the time indicated," with
>>>> sample values including "draft", "candidate", "published", and so on.
>>>>  From its name and definition, it's presumably intended to apply to an
>>>> entire document (although it's also available on <bibl>, <object> and
>>>> some other elements which are presumably held to constitute
>>>> document-level units).
>>>>
>>>> We have an increasing need to track the status (draft, proofed,
>>>> published and so on) not of entire documents but of individual items in
>>>> resource lists, such as:
>>>>
>>>> <person>
>>>> <entry>/<entryFree>
>>>> <place>
>>>> <bibl> (already has @docStatus, but is it appropriate for this?)
>>>> <item>
>>>>
>>>> The use-case is, for example: We have a large personography which is
>>>> constantly being added to and edited. New empty <person> entries are
>>>> added ("proposed"); content of items is drafted ("draft"); then they
>>>> are
>>>> proofed, approved, published and so on; and occasionally they are
>>>> deprecated and withdrawn. Across the personography, individual entries
>>>> are always at different stages in this process.
>>>>
>>>> How have other TEI projects handled this? It would be really handy for
>>>> us to have @status available on these entity elements, but there may be
>>>> effective ways to use existing elements or attributes that we haven't
>>>> thought of.
>>>>
>>>> All help appreciated,
>>>> Martin
>>>> --
>>>> -------------------------------------
>>>> Humanities Computing and Media Centre
>>>> University of Victoria
>>>> [hidden email]
>>>>
>>>
>>> --
>>> -------------------------------------
>>> Humanities Computing and Media Centre
>>> University of Victoria
>>> [hidden email]
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]