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


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