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

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

Oh of course you're right. I don't know why I was thinking only of structural specializations, and not thinking of domain specializations.

So are we saying that domain specializations alone suffice to justify a distinct abstract type? 

The semantic distinction on the abstract layer is that <descriptive> refers to a class or category and is atemporal, and <fkat> refers to an individual instance of such a class or category at a specified time. A remaining argument for specializing <record> from <descriptive> and dropping <fkat> is that it would be easier to make that class-instance relationship explicit. An argument in favor of retaining <fkat> is that the ancestor for domain specializations of particular record types would not also be the ancestor of <reference>, <resource>, and other class-specifying types.

Which of the specialized particular record types gets to be called <record>? All the others will be called <X-record> or <Y-record> or some such. Why not use <record> as the name of the abstract type if every one of its specializations is a particular kind of record?

<empirical> is a nice solution if we think we are going to specialize something other than records from it. Perhaps something other than a record could refer to instances of a <description> class. What might that be?

	/Bruce

> -----Original Message-----
> From: Tim Grantham [mailto:tgrantham@timgrantham.com] 
> Sent: Tuesday, April 13, 2010 5:38 PM
> To: Bruce Nevin (bnevin); 'Hanna, Rob'
> Cc: dita-busdocs@lists.oasis-open.org
> Subject: RE: [dita-busdocs] RE: Adjectives vs nouns
> 
> 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_workgr
> oups.php 
> 
> 
>