OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-busdocs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita-busdocs] RE: Adjectives vs nouns


Well, nor is a particular series of procedure steps a document type. Instances of a type are stable documents that can be stored, tracked, discovered, held, and at EOL destroyed. The type specifies a common structure.
 
    /B


From: josef.pellizzari@novartis.com [mailto:josef.pellizzari@novartis.com]
Sent: Wednesday, April 14, 2010 11:18 AM
To: dita-busdocs@lists.oasis-open.org
Subject: Re: [dita-busdocs] RE: Adjectives vs nouns


A comment from a records-obsessed industry: I don't think that a record is a document type. In our business (pharma) almost everything can become a record, typically reports of any kind of study (tests in animals or humans), chemical stability reports, raw data,  meeting minutes, and so on. Definitely more types than we can handle and often not what we would consider a business document. For us handling something as a record means to ensure that it's not changed anymore, that we track it's whereabouts, are able to exercise legal discovery/hold and some more things. After a certain period we are no longer legally required to keep the record, which is then disposed of unceremonously.

Josef


"Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote on 13.04.2010 17:02:31:

> From the example, the record type is for all sorts of records, and the
> names 'temporal' and 'event' are alike too narrow. (The activity of
> making the record is an event, but such event information is metadata
> about the content of the record itself. Likewise, the activity is an
> event when someone measures attributes such as height and weight on
> different occasions, but the record is not a record of that event.)
>
> > Please note: neither of my sons were harmed in the making of these
> examples.
>
> Thanks, glad to know! And this nicely illustrates the point.
>
> > The record abstract type is, in my estimation, a key
> > information type used in business communication (and not
> > typically in technical publications). It would be specialized
> > to accommodate any record such as a test result, a incident
> > report, a trip report, minutes, etc. Without an abstract
> > type, we could shovel this type of information somewhere
> > else, but I don't think it would fit as elegantly. My opinion
> > is that this information type is unique in its behavior and
> > relationship to other types of information.
>
> Clearly, it should be a specialized document type. The question is, from
> what should it be specialized? Should it be a document type specialised
> from the abstract <description> type, or should it be a document type
> specialized from a virtually identical abstract type? All the abstract
> types being specialized from the even more abstract <topic> type that is
> in DITA now.
>
>    /Bruce
>
> > -----Original Message-----
> > From: Hanna, Rob [mailto:Rob.Hanna@wolterskluwer.com]
> > Sent: Tuesday, April 13, 2010 8:52 AM
> > To: Bruce Nevin (bnevin); tgrantham@timgrantham.com;
> > rockley@rockley.com
> > Cc: manning@rockley.com; zrendon@ptc.com; Bruce Nevin; Hanna, Rob
> > Subject: RE: Adjectives vs nouns
> >
> > Good day, Bruce.
> >
> > Thank you so much for your thorough explanations and
> > well-constructed arguments.
> >
> > One of the major distinctions for the record-type information
> > is that unlike the other types of information, this
> > information is essentially static. A description of something
> > or someone will change as that thing or person changes.
> >
> > For example, today my son is 11 years old and 5' 7". In three
> > years, my son will be 14 years old and 6' 9". The same piece
> > of content will be used to describe my son except that it
> > will be a different version of that same content - a version
> > of the content from when my son was 11 wouldn't normally
> > co-exist with a version from when my son was 14. While I have
> > used a date to illustrate my point, no date is necessary to
> > describe my son - the assumption is that the description is
> > accurate as of the date of publication and is in present-tense.
> >
> > A record is different in that only one accepted version of
> > the record would normally ever exist. The record may go
> > through a number of iterations to get to version 1.0 but you
> > wouldn't normally ever see a version 2.0 of the record.
> >
> > For example, on June 14 2009, my son fell off his bike
> > requiring stitches on his left knee. On October 17 2009, my
> > son fell of a playground slide requiring a partial cast on
> > his right arm. These are both two separate records each with
> > a required date stamp. I won't ever revise either record
> > except to make corrections as may be necessary.
> > Both records would co-exist within the same space and would
> > be aggregated to form a medical history for my son. Please
> > note: neither of my sons were harmed in the making of these examples.
> >
> > The record abstract type is, in my estimation, a key
> > information type used in business communication (and not
> > typically in technical publications). It would be specialized
> > to accommodate any record such as a test result, a incident
> > report, a trip report, minutes, etc. Without an abstract
> > type, we could shovel this type of information somewhere
> > else, but I don't think it would fit as elegantly. My opinion
> > is that this information type is unique in its behavior and
> > relationship to other types of information.
> >
> > > So we'd have to specialize children of <abstract>.
> > And that means we need the parent <abstract> (or a
> > specialization of it) as a container element for <summary>,
> > <stamp>, <date-time>, <location>, and <occurrence>.
> >
> > This should in fact be a specialization of <abstract>.
> >
> > > On the other hand, why do we want to eliminate <abstract> from
> > [descriptive]? I have often found that users want to say more
> > before the body than properly will fit in <shortdesc>.
> >
> > I don't think that we should remove abstract from
> > descriptive. The pseudo code example in the paper is not
> > meant to be complete in anyway - just illustrative of the concept.
> >
> > I hope this makes sense.
> >
> > Cheers,
> > Rob Hanna
> >
> >
> > -----Original Message-----
> > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > Sent: Monday, April 12, 2010 5:48 PM
> > To: tgrantham@timgrantham.com; Hanna, Rob; rockley@rockley.com
> > Cc: manning@rockley.com; zrendon@ptc.com; Bruce Nevin
> > Subject: RE: Adjectives vs nouns
> >
> > Whatever we decide, it will suggest henceforth to users the
> > boundaries of the range of content types that they might
> > specialize from it in the future.
> >
> > That's why I asked if it concerns records only of events or
> > transactions, or if it includes other kinds of records. As
> > presently defined, it's strictly temporal. Here's the given
> > definition:
> >
> >     Information that reports on an event.
> >     Records specific time and/or place of
> >     the occurrence and summarizes the outcome.
> >
> > Thinking of other types of records such as vital statistics
> > or medical records, I realized that such records might be
> > thought of as instances of the <reference> type (which is
> > modeled under the [descriptive] abstract type, even though
> > it's currently specialized from <topic>). (I hope my ad hoc
> > use of square braces for abstract types here is clear.
> > Obviously, not good as an ongoing convention.)
> >
> > A pertinent question, then, is: what distinguishes this
> > [temporal/archival/transactional] type from the more general
> > [descriptive] type? And do we really need that distinction?
> > Could the <event> type be specialized from the [descriptive]
> > abstract type? If not, why not?
> >
> > Every distinction we make must be able to stand up to this
> > kind of question. What is its justification? By clarifying
> > the distinctions we will be more clear about the various
> > criteria that users must apply before specializing new
> > document type X from this abstract type rather than from that one.
> >
> > Another question: is it likely to serve as the specialization
> > ancestor of a useful family of document types? Now on this
> > one I'm having some trouble imagining anything specialized
> > from it except a record of an event. Is that sufficient
> > justification for an entire abstract type as a basis for
> > specialization?
> >
> > A third question concerns semantic distinction in the
> > definitions. How distinct are the definitions of the
> > [temporal/archival/transactional] type, quoted above, and the
> > [descriptive] type? The [descriptive] abstract type has the
> > following definition:
> >
> >     Describes specific information about an object.
> >     It may describe characteristics of an object,
> >     a person, or a place. ...
> >
> > This could easily encompass both definitions, something like:
> >
> >     Describes specific information about something.
> >     It may describe characteristics of an object,
> >     a person, a place, or an event. ...
> >
> > The more detailed definition ("reports on an event. Records
> > specific time and/or place of the occurrence and summarizes
> > the outcome.") applies to the <event> or <record> document
> > type specialized from it.
> >
> > Indeed, what difference is there between the abstract type
> > and the specialized element? It seems to me that the
> > specialized element accounts for the entire range of
> > semantics of the proposed abstract type, with nothing left
> > over for specializing other sibling elements. So that's a
> > negative answer to our third question. A 'family' of one
> > specialized element makes the abstract type of limited usefulness.
> >
> > A fourth question concerns their structural similarity.
> > Comparing their proposed structures, the [descriptive] type
> > has only <shortdesc> before the body element; but instead of
> > <shortdesc>, the [temporal/archival/transactional] type has a
> > series of specialized
> > elements: <summary>, <stamp>, <date-time>, <location>, and
> > <occurrence>.
> > The body is identical, except that [descriptive] includes a
> > <characteristics> element at the end. Here are the two models
> > as given in pseudocode:
> >
> > <descriptive>
> > <title>
> > <shortdesc>
> > <descbody>
> > <detail>
> > <sublist>
> > <characteristics>
> > <related-links>
> >
> > <temporal>
> > <title>
> > <summary>
> > <stamp>
> > <date-time>
> > <location>
> > <occurrence>
> > <temporalbody>
> > <details>
> > <sublist>
> > <related-links>
> >
> > What is the specialization ancestor of these pre-body
> > elements <summary>, <stamp>, <date-time>, <location>, and
> > <occurrence>? Here's the content model of <topic>:
> >
> > <topic>
> > <title>
> > <titlealts>?
> > (<shortdesc> | <abstract>)?  
> > <prolog>?
> > <body>?
> > <related-links>?
> >
> > Superficially, these new elements look like the children of
> > <prolog>, but we can't go there because we're talking about
> > content, not metadata about the content. So we'd have to
> > specialize children of <abstract>.
> > And that means we need the parent <abstract> (or a
> > specialization of it) as a container element for <summary>,
> > <stamp>, <date-time>, <location>, and <occurrence>. Or am I
> > misunderstanding something basic about specialization? That's
> > always possible. It wouldn't be the first time I had
> > displayed ignorance for all to see.
> >
> > On the other hand, why do we want to eliminate <abstract>
> > from [descriptive]? I have often found that users want to say
> > more before the body than properly will fit in <shortdesc>.
> > If we retain the (<shortdesc> | <abstract>)? choice as in
> > <topic> then the children of <abstract> are available to
> > specialize as <summary>, <stamp>, <date-time>, <location>,
> > and <occurrence>. And if we do that, there is no structural
> > reason for a separate abstract type, the <event> element can
> > happily be a specialization of [descriptive].
> >
> > I find myself concluding that the main reason we are having
> > so much trouble coming up with a good name for this abstract
> > type is because we don't need it and shouldn't posit it.
> >
> >    /Bruce
> >
> >
> > > -----Original Message-----
> > > From: Tim Grantham [mailto:tgrantham@timgrantham.com]
> > > Sent: Monday, April 12, 2010 3:48 PM
> > > To: 'Hanna, Rob'; Bruce Nevin (bnevin); rockley@rockley.com
> > > Cc: manning@rockley.com; zrendon@ptc.com
> > > Subject: RE: Adjectives vs nouns
> > >
> > > I favour "transactional" or "archival".
> > >
> > > How about "transcriptive"?
> > >
> > > Tim.
> > >
> > > -----Original Message-----
> > > From: Hanna, Rob [mailto:Rob.Hanna@wolterskluwer.com]
> > > Sent: Monday, April 12, 2010 3:37 PM
> > > To: Bruce Nevin (bnevin); rockley@rockley.com
> > > Cc: manning@rockley.com; tgrantham@timgrantham.com;
> > zrendon@ptc.com;
> > > Hanna, Rob
> > > Subject: RE: Adjectives vs nouns
> > >
> > > I completely agree with Bruce. We aren't suggesting that we
> > don't need
> > > explanatory, descriptive, and procedural - we are simply
> > acknowledging
> > > that we can achieve what we are working towards using concept,
> > > reference, and task until such time as the TC can render
> > judgment on
> > > the underlying abstract layer.
> > >
> > > How about:
> > >
> > > Event-based Information. Or
> > > Record-based Information?
> > >
> > > I'm still favouring Transactional Information.
> > >
> > > Cheers,
> > > Rob Hanna
> > >
> > > -----Original Message-----
> > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > > Sent: Monday, April 12, 2010 1:10 PM
> > > To: rockley@rockley.com
> > > Cc: manning@rockley.com; Hanna, Rob;
> > > tgrantham@timgrantham.com; zrendon@ptc.com; Bruce Nevin (bnevin)
> > > Subject: RE: Adjectives vs nouns
> > >
> > > The reason for adjectival names was to help distinguish the
> > abstract
> > > layer from the specific types specialized from it. I think that
> > > criterion still applies.
> > >
> > > It's a little confusing to say we're going to *continue*
> > with concept,
> > > task, and reference. Rather, they're not going away any
> > time soon, so
> > > we're working around them. That's not a motivation for
> > using nouns as
> > > labels in the abstract layer.
> > > Rather, it's even more important to emphasize that the
> > existing base
> > > types are of a different order from the abstract layer.
> > >
> > > Rather than saying we're going to continue with the
> > <concept>, <task>,
> > > and <reference> types, we acknowledge that they necessarily
> > persist as
> > > specializations of <topic> until the TC implements the
> > abstract layer
> > > as part of the standard--which of course they might never
> > do, but we
> > > hope they will. These current base types have an uncomfortable
> > > relationship to our proposed specialization framework.
> > > Hierarchically, they are on the same level as the abstract types,
> > > since they are immediately specialized from <topic>, but there is a
> > > place reserved for them to be specialized from <explanatory>,
> > > <descriptive>, and <procedural> in the abstract layer.
> > >
> > > They aren't entirely incommensurate, but to share content
> > one has to
> > > generalize all the way back to <topic>. Thus, if someone were to
> > > specialize <design> from <explanatory> and someone wanted
> > to use that
> > > specialized content in an unspecialized environment, they
> > would have
> > > to generalize to <topic>. If in some future release of DITA
> > <concept>
> > > is also specialized from <explanatory> then they could
> > generalize back
> > > to <explanatory> and get a closer fit for processing in the
> > > unspecialized environment.
> > >
> > > Thinking of records, how about archival?
> > >
> > > How about moving the semantics of 'event' up to the abstract layer,
> > > and let the busdocs type be 'record'? I haven't thought of any
> > > adjectives around 'event' but it does open up the search
> > field a bit.
> > > We've been asking what words cluster around 'record', and
> > we can also
> > > ask what words cluster around 'event'.
> > >
> > >    /Bruce
> > >
> > > > -----Original Message-----
> > > > From: rockley@rockley.com [mailto:rockley@rockley.com]
> > > > Sent: Monday, April 12, 2010 12:22 PM
> > > > To: Bruce Nevin (bnevin)
> > > > Cc: manning@rockley.com; rob.hanna@wolterskluwer.com;
> > > > tgrantham@timgrantham.com; zrendon@ptc.com; rockley@rockley.com
> > > > Subject: Adjectives vs nouns
> > > >
> > > > At the end of today's meeting we agreed to send a list of
> > > the possible
> > > > options for temporal to the list and to point out that we need an
> > > > adjective form of the word. However, we may wish to modify our
> > > > position on the use of an adjective for the following reason.
> > > >
> > > > Our abstract layer currently consists of:
> > > >
> > > > -Procedural
> > > > -Explanatory
> > > > -Descriptive
> > > > -Advisory
> > > > -Criterial
> > > > -'Temporal'
> > > >
> > > > However, we are going to continue with concept, task and
> > reference;
> > > > not procedural, explanatory and descriptive.
> > > >
> > > > Therefore, should we drop the requirement for an adjective
> > > form of the
> > > > term?
> > > >
> > > > I wanted to check on our feelings on this criteria before I
> > > send the
> > > > list of options to the subcommittee.
> > > >
> > > > Please let me know by EOB today what your thoughts are on
> > this so I
> > > > can post the list.
> > > >
> > > > Thanks.
> > > >
> > > > Ann
> > > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]