Loading ...
Sorry, an error occurred while loading the content.
 

Re: Choosing the right granularity level for a topic

Expand Messages
  • juliov27612
    I would probably put the ingredients into the if keeping things inside a task topic. I might use or to hold a brief description
    Message 1 of 9 , Apr 5, 2013
      I would probably put the ingredients into the <prereq> if keeping things inside a task topic. I might use <abstract> or <shortdesc> to hold a brief description of the recipe. (I don't think <context> is semantically right for this.)

      Julio J. Vazquez
      SDI Global Solutions

      --- In dita-users@yahoogroups.com, Mica Semrick <paperdigits@...> wrote:
      >
      > I get what you're saying about conrefs or conkeyrefs. But where exactly
      > would you conref that into the task? prolog? Usually a recipe has a
      > struture of
      >
      > Name
      >
      > ingredient table: ingredient + quantity
      >
      > prep steps
      >
      > I guess it really depends on exactly how much information you have. Given
      > the cookbook example, I could easily see a reference topic that holds all
      > the ingredients for all recipes. This reference topic could also other
      > info, maybe country of origin or some classification of taste (sweet,
      > salty) or other ingredients that complement.
      >
      >
      > On Thu, Apr 4, 2013 at 2:34 PM, wildmountainspirit <
      > wildmountainspirit@...> wrote:
      >
      > > **
      > >
      > >
      > > Usually, recipes have different combinations of ingredients, which is why
      > > I suggested conrefs. If each recipe has exactly the same ingredients, then
      > > I agree with making the ingredients a reference topic. I also agree that
      > > the recipe procedure should be a task.
      > >
      > >
      > > --- In dita-users@yahoogroups.com, Mica Semrick <paperdigits@> wrote:
      > > >
      > > > I would make the ingredients a reference, and the prep at task.
      > > >
      > > >
      > > > On Thu, Apr 4, 2013 at 8:55 AM, wildmountainspirit <
      > > > wildmountainspirit@> wrote:
      > > >
      > > > > **
      > >
      > > > >
      > > > >
      > > > > Actually, that is the conref= attribute (not <conref>). Sorry. Haven't
      > > had
      > > > > my full allotment of coffee yet this morning. :)
      > > > >
      > > > >
      > > > > --- In dita-users@yahoogroups.com, "wildmountainspirit"
      > > > > <wildmountainspirit@> wrote:
      > > > > >
      > > > > > I would put the ingredients in a separate file, and then use <conref>
      > > > > wherever they are needed in a recipe.
      > > > > >
      > > > > > As to whether to make each ingredient a separate topic, that may
      > > depend
      > > > > on your preference. For short information, like product names, I use
      > > one
      > > > > common file. For longer information, such as glossary term
      > > definitions, I
      > > > > create separate files for each term.
      > > > > >
      > > > > > HTH,
      > > > > > Julie
      > > > > >
      > > > > > --- In dita-users@yahoogroups.com, "Lech Rzedzicki" <xchaotic@>
      > > wrote:
      > > > > > >
      > > > > > > Hi.
      > > > > > >
      > > > > > > I am dealing with a project where there is a natural level for
      > > > > splitting into topics - this would map to a section in a printed book.
      > > > > > > It could make managing those topics a little easier...
      > > > > > > However inside that section there is always a data portion that is
      > > > > highly reusable etc and a descriptive portion that is usually not.
      > > > > > > To give you an example, look at a cooking recipe:
      > > > > > > the ingredients part would be the data portion and the preparation
      > > > > steps is the descriptive part.
      > > > > > >
      > > > > > > How would you go about modeling that in DITA?
      > > > > > > Would you make ingredients part a separate topic (if not, why not)?
      > > > > > > Just theoretically, would you make every ingredient an individual
      > > > > topic (again why not) ?
      > > > > > >
      > > > > > > Regards and looking forward to some feedback and links to other
      > > > > resources,
      > > > > > >
      > > > > > > Lech
      > > > > > >
      > > > > >
      > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      > >
      >
    • Lech Rzedzicki
      Thanks for the answers so far - I agree with most comments and I am glad we re sticking with the recipe book example - it really fits my actual problem space.
      Message 2 of 9 , Apr 5, 2013
        Thanks for the answers so far - I agree with most comments and I am glad we're sticking with the recipe book example - it really fits my actual problem space.
        As correctly pointed out - rarely can a person reuse a whole ingredient list as is, or a whole recipe.
        What happens more often is that one reuses a single ingredient or modifies the recipe slightly.
        In case of reusing a single ingredient, keeping all possible ingredients in the world in on single topic does not sound sensible.
        Would having a topic for every given ingredient make more sense?
        How about storing variations of a recipe - here I'd say conditional profiling could be appropriate, but is it easy to manage?
        Let's say we have a vegetarian version of a salad, with soy instead of chicken, in general, in almost any output I want that as a separate item, but I want them to share as much as they can and definitely keep the relationship.
        Again, what's the BEST practice?
      • Mica Semrick
        ... Here is a terrible answer: The best practice is one that makes sense for the scope of your project and your data. The cookbook example may be excellent and
        Message 3 of 9 , Apr 5, 2013
          Again, what's the BEST practice?

          Here is a terrible answer: The best practice is one that makes sense for the scope of your project and your data.

          The cookbook example may be excellent and fit your use-case, but there is probably a large variation in cookbooks (I can barely operate a microwave correctly... so I'm certainly not an SME in this case). Again, scope is important. If you want every ingredient in the world, then a filesystem with files probably doesn't make sense. A database does. 

          Are you trying for a cookbook that records every recipe ever known? That cookbook will have quite a different information architecture than the cookbook I put together of my family's secret recipes.

          In a general sense, I'd try and isolate your reusable content from your non-reusable content, then figure out the best way to join the two in the publication. Is it conkeyrefs? Is it conrefpush? Is it a related link? xref? nested topicrefs? 

          Perhaps you can share a bit about the scope of your cookbook?

          -mica


          On Fri, Apr 5, 2013 at 7:35 AM, Lech Rzedzicki <xchaotic@...> wrote:
           

          Thanks for the answers so far - I agree with most comments and I am glad we're sticking with the recipe book example - it really fits my actual problem space.
          As correctly pointed out - rarely can a person reuse a whole ingredient list as is, or a whole recipe.
          What happens more often is that one reuses a single ingredient or modifies the recipe slightly.
          In case of reusing a single ingredient, keeping all possible ingredients in the world in on single topic does not sound sensible.
          Would having a topic for every given ingredient make more sense?
          How about storing variations of a recipe - here I'd say conditional profiling could be appropriate, but is it easy to manage?
          Let's say we have a vegetarian version of a salad, with soy instead of chicken, in general, in almost any output I want that as a separate item, but I want them to share as much as they can and definitely keep the relationship.
          Again, what's the BEST practice?


        Your message has been successfully submitted and would be delivered to recipients shortly.