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

["Tim Grantham" <tgrantham@timgrantham.com>]

Not all useful specializations from an abstract type will result in
restrictions on the abstract type's content model. Some, as in the <policy>
info-type I'm specializing from the [advisory] abstract type, are
specialized simply to provide an expanded a set of domain-specific element
names: <benefit>, <exclusion>, <condition>, etc. (all specialized from the
[advisory]/<rule> element.

For our [fkat] abstact type, we could have at its core, the <record>
element, specialized from the base <abstract> type. Specializations of this
could consist of simply providing an element name that is more familiar to
authors in the application: <event>, <snapshot>, <incident>, <instance>,
<alarm>, and so on.

I think we have consensus that the core element of the abstract info-type is
<record>. So how about the following content model for [fkat]:

title, titlealts?, record?, prolog?, fkatbody?, related-links?,
fkat-info-type*

It looks to me like the base <abstract> element that <record> is specialized
from is sufficiently flexible for any specialization of <record> to capture
the essential content of any type of record.

Regards,
Tim.

-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] 
Sent: Tuesday, April 13, 2010 3:37 PM
To: Hanna, Rob
Cc: dita-busdocs@lists.oasis-open.org
Subject: [dita-busdocs] RE: Adjectives vs nouns

Formerly-known-as-temporal -- I think I'll call it <fkat> for present
convenience.

What differences are there between this abstract type <fkat>, and the
document type <record> which is specialized from it? What restrictions on
<fkat> produce <record>? The differences between the abstract type and the
specialized document type will tell us how much 'slack' there is for
specializing other things from <fkat>. If they're in 1-1 correspondence then
<fkat> is meaningless.

What are the differences between <fkat> and <descriptive> at the abstract
type level? And to ask the first question again from this sideways
perspective, which of those differences are not also in the document type
<record>?

What else might be specialized from the abstract type <fkat>? This is harder
to answer because we have no use cases. But looking at the 'slack', the
difference between <fkat> and <record>, is it possible to make different
restrictions on <fkat> that might produce different specialized document
types? Document types specialized from <fkat> must be distinct from those
specialized from <descriptive. The distinctions between the two sets of
document types will flow from the semantic characteristics that distinguish
<fkat> from <descriptive> on the abstract type level. 

Personally, I haven't been able to think of anything other than <record>
that might be specialized from <fkat> and I haven't heard any distinctions
of <fkat> from <descriptive> that are not also characteristics of <record>.
So far as I can tell, there's a 1-1 correspondence between <fkat> and
<record>.

This is what I get as essential about these:

¸,ø¤º°`°º¤ø,¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤º°`°º¤ø,¸

<descriptive> ==> <reference>, <resource>
_________________________________________

features that characterize X as a class
generally understood to be stable through time


<fkat> ==> <record>
___________________

features of an instance of the class X at a specified time value given for a
feature may change such change may occasion update or versioning

¸,ø¤º°`°º¤ø,¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤º°`°º¤ø,¸

Thus, the <reference> for flashlights will say that it has a battery; the
<record> for a particular flashlight may say that it passed inspection, or
that its battery is dead, or that its battery was replaced, each with a
timestamp. A <reference> on human anatomy describes the limbs; a medical
record for your son documents a fracture. The <resource> for a programmer
specifies proficiency in C++ and Java, and the corresponding personnel
<record> may mention the C++ coding bugs that other people had to fix.

A <reference> describes features of a kind of thing; a <resource> describes
features that characterize a role or organizational entity such as a group.
The PPT says it can be a particular person, though, and this needs
clarification. But in general, these specializations of <descriptive> are
concerned with the features that define a category or class. 

A <record> is a doctype that describes features of an individual at a
particular time. The individual is an instance of a class that is (or
implicitly can be understood to be) described elsewhere by a <reference>.
The features (flashlight, left arm) are the same, but the <record> includes
the state of certain features (battery dead, left arm fractured) and
includes the time of observing that state (which may be but need not be the
time of making the record).

This suffices to justify a distinct specialization. Answers to semantic
questions of the sort posed above are needed in order to clarify whether
<record> should be specialized from the same abstract type, <description>,
or from a distinct abstract type, <fkat>. And we only have to come up with a
real name for <fkat> if we choose the latter course.

	/Bruce


> -----Original Message-----
> From: Hanna, Rob [mailto:Rob.Hanna@wolterskluwer.com]
> Sent: Tuesday, April 13, 2010 1:41 PM
> To: Bruce Nevin (bnevin)
> Cc: dita-busdocs@lists.oasis-open.org; Hanna, Rob
> Subject: RE: Adjectives vs nouns
> 
> > alternatively specialize <record> from the abstract
> <descriptive> type
> 
> The purpose of the Descriptive abstract type is to describe 
> characteristics of something or someone. This is most closely aligned 
> with the <reference> topic type. A record isn't used to describe 
> characteristics of something - it is used to record the state of 
> something at a given point in time. The record is usually marked by a 
> change in state (i.e., an event). A description is fluid in present 
> time whereas a record-type topic is static - frozen in time. I believe 
> that the two are sufficiently distinct to both be specialized from 
> <topic>.
> 
> > along with <resource> and possibly a BusDocs simplification of 
> > <reference>
> >         |--Procedural     | <reference> (BusDocs)
> >         |--Explanatory ---+ <resource>
> > topic---+--Descriptive    | <record>
> >         |--Advisory
> >         |--Criterial
> 
> I would suggest that both <reference> and <resource> are descriptive 
> information types and not explanatory. My belief is that <record> 
> comes from Topic-Formerly-Known-as-Temporal which stands alone as an 
> abstract information type.
> 
> > I have qualms about specializing simplified BusDocs doctypes called 
> > <concept>, <task>, and <reference> from the abstract layer,
> parallel
> > to the standard base types specialized directly from <topic>.
> 
> I understood that we reached a consensus yesterday that we would 
> introduce the simplified versions of concept, task, and reference to 
> the TC for future consideration along with Advisory, Criterial, and 
> Topic-Formerly-Known-as-Temporal. In the meantime, we create the 
> specializations of the three new abstract types from <topic> and use 
> the classic DITA <concept>, <task>, and <reference> to specialize 
> from.
> 
> > It may be that there's no issue because content sharing is so 
> > diminished in business docs, and practically nil between
> business docs
> > and tech docs.
> 
> We shouldn't underestimate the value of sharing between domains even 
> if it is currently rarely achievable. Hopefully we can contribute a 
> solution that will make this more possible.
> 
> Cheers,
> Rob Hanna
> 

---------------------------------------------------------------------
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