[IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Glenda Browne
Following comments at our meeting, and thoughts about all these definitions, I think we need to clarify our definition of 'entry', and say how much it includes, and to think about when we mean 'entry' and when we mean 'term'.
To me an entry is a locator and all of the terms that belong to it. So 'dogs 45' is an entry, and so is 'dogs: training 63'. (The colon indicating that a subheading follows). (A cross reference and the main heading it is attached to is also, perhaps, an entry).
But I have seen on our mailing list the use of 'entry' to mean just the final term and its locator, eg, 'training 63'.
It is hard to say which is generally accepted in the indexing community. The ISO standard uses entry to mean what we call entry array; the NISO technical report definition allows for multilevel headings (ie, would call 'dogs: training 63' an entry); LibreOffice uses the second definition (eg, 'training 63' would be an entry); some software uses yet another definition. I think the indexing community mainly uses the NISO definition, but as Dave said we also use it casually in the context of the book, eg, 'I have an average of 10 entries per page'.
I'm fine with either, depending on what people think is useful for the way ebooks work, but I think we need to expand the example to make it clear which one we are using.
I also think we are using the word 'entry' in discussions when we mean 'term'. Eg, when we talked about 'child entries' we really meant 'child terms'. If we use the first definition above, it makes no sense to talk about 'entry level' or 'main entry' as the 'entry', as defined, spans all levels. If we use the second definition, and 'training 63' is the 'entry', then it doesn't make sense to call 'dogs' its 'main entry'.
Another message follows on heading vs entry.
Cheers,
Glenda.
entry
Term + locator OR term + cross-reference. For legacy data an entry could include a string of locators
For example, in the entry "dogs, 45", the string "dogs" is the term and the string "45" is the locator
term
Character string, representing the indexable item -- e.g., a name, place, concept, topic, or any one of an almost infinite number of things.
-- Glenda Browne Indexer, Writer, Teacher Member of the IDPF EPUB Indexes Working Group Author of The Indexing Companion Workbook: Book Indexing http://www.webindexing.biz http://en-gb.facebook.com/pages/The-Indexing-Companion-Book-Indexing-Workbook/82315763536
Bill Kasdorf
I would just observe that “dogs: training 63” is really just a way of associating the subentry (“training 63”) with the parent entry that it’s the child of (“dogs”), or perhaps more precisely to situate it as part of the entry _array_ about “dogs.” In the context of the full index itself, you don’t need to spell out “dogs:” but if you look at the subentry in isolation, “training 63” is either ambiguous or meaningless without specifying what it’s the child of. But in this situation I think it’s perfectly appropriate to refer to “dogs: training 63” as a subentry.—Bill K
MicheleR
> I would just observe that �dogs: training 63� is really just a way of
> associating the subentry (�training 63�) with the parent entry that it�s the
> child of (�dogs�), or perhaps more precisely to situate it as part of the entry
> _/array/_ about �dogs.� In the context of the full index itself, you don�t need
> to spell out �dogs:� but if you look at the subentry in isolation, �training 63�
> is either ambiguous or meaningless without specifying what it�s the child of.
> But in this situation I think it�s perfectly appropriate to refer to �dogs:
> training 63� as a subentry.�Bill K
I was going to respond to this but Bill has pretty much exactly said what I
would say :) +1, Bill!
Michele
--
Those who dream by night in the dusty recesses of their
minds wake in the day to find that all was vanity;
But the dreamers of the day are dangerous men, for they
may act their dream with open eyes, and make it possible.
~ T.E. Lawrence.
Glenda Browne
Glenda.
On 9/05/2012 11:42 AM, MicheleR wrote:
> On 5/8/2012 9:33 PM, Bill Kasdorf wrote:
>> I would just observe that �dogs: training 63� is really just a way of
>> associating the subentry (�training 63�) with the parent entry that
>> it�s the
>> child of (�dogs�), or perhaps more precisely to situate it as part of
>> the entry
>> _/array/_ about �dogs.� In the context of the full index itself, you
>> don�t need
>> to spell out �dogs:� but if you look at the subentry in isolation,
>> �training 63�
>> is either ambiguous or meaningless without specifying what it�s the
>> child of.
>> But in this situation I think it�s perfectly appropriate to refer to
>> �dogs:
>> training 63� as a subentry.�Bill K
>
>
> I was going to respond to this but Bill has pretty much exactly said
> what I would say :) +1, Bill!
>
> Michele
--
MicheleR
> But which of those fits your definition of 'entry'?
>
a subentry of the former?
Michele
> Glenda.
>
> On 9/05/2012 11:42 AM, MicheleR wrote:
>> On 5/8/2012 9:33 PM, Bill Kasdorf wrote:
>>> I would just observe that �dogs: training 63� is really just a way of
>>> associating the subentry (�training 63�) with the parent entry that it�s the
>>> child of (�dogs�), or perhaps more precisely to situate it as part of the entry
>>> _/array/_ about �dogs.� In the context of the full index itself, you don�t need
>>> to spell out �dogs:� but if you look at the subentry in isolation, �training 63�
>>> is either ambiguous or meaningless without specifying what it�s the child of.
>>> But in this situation I think it�s perfectly appropriate to refer to �dogs:
>>> training 63� as a subentry.�Bill K
>>
>>
>> I was going to respond to this but Bill has pretty much exactly said what I
>> would say :) +1, Bill!
>>
>> Michele
>
--
Seize the moment. Remember
all those women on the 'Titanic' who
waved off the dessert cart.
~ Erma Bombeck
+++++++++++++++++++++++++++
David K. Ream
I went to a meeting after the conf call ended so I missed all the fun I’m glad you guys settled everything. (right).
In Bill’s example below, I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels, or a main heading and a subheading.
Dictionaries refer to entries too. An entry therein is a word/term you look up and it consists of everything attached to it, such as the etymology, pronunciation (scope notes like stuff), and each sense and part of speech which are look subentries. (no locators but there are cross references sometimes.)
Here’s what I wrote up / modified after the meeting and reading the postings. It is mildly interesting to me that we have such a hard-time using English to define all this. I have consulted on SGML and XML DTDs that define index structures that can be parsed for correctness. So I know it can be done.
entry
An entry is a term that can be associated with one or all of
· an locator list
· a cross-reference list
· a scope note
and can be the parent of one or more subentries. (one of the four situations must occur, or all four could.)
entry array
An entry (at any level) and all of its subentry descendants, locators, cross references and other information. (A main entry with no subentries would technically still be an entry array but only have 1 level in it, i.e., it has no children.)
main entry
A highest-level entry, i.e., it has no parent.
subentry
An entry subordinate to a main entry or subentry, i.e., it has a parent and might have children.
entry level
The depth of an entry with an entry array. A main entry is level 1.
group
A set of main entry arrays, for example, all main entries beginning with "A" or that share some other common characteristic. It may include a group heading.
Romain Deltour
I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels
grooming, 96
Glenda Browne
Sorry, if I said a subheading is a level 1 entry I meant level 2. To an indexer a subheading is always directly under a main heading. If it is the next level down (ie level 3 entry) we call it a subsubheading. But if it doesn't matter as far as programming goes, then I'm fine with this. If we define only main headings and subheadings, it seems to me that 'subheading' will be synonymous with 'child entry'. Subsubheading could be described by combining 'subheading' with a level number if its level was crucial.
More comments inline below...
On 9/05/2012 10:40 PM, Romain Deltour wrote:
I mostly agree with Dave's definitions below, but I think some points still needs to be clarified:
A) Subentries
Glenda said that in the indexing world a "subentry" has an absolute position: it is a level 1 entry. �This is conflicting with the definition below and needs to be clarified. I would personally vote for "subentry" meaning "an entry that has a parent, i.e. an entry that is not a main entry" (=Dave's definition) rather than the absolute "level 1 entry", but if this is conflicting with the indexers lingo we might want to simply ditch the word "subentry".
B) Entry ancestors context
Dave wrote:
I think this example below (and what I think are Bill's comments above, which I just noticed as new content) comes back to the difference between a term and an entry. 'dogs' in the entry array below is a term, but in my usage it is not an entry. To me an entry is everything that expresses the content that a locator will take you to. So 'dogs' would be part of three entries -� 'dogs: feeding� 72', 'dogs: grooming� 72', and� 'dogs: training� 72. 'Dogs' is not an entry because it doesn't lead to anything. If the entry array was:I disagree. "dogs: training 63" is a subentry as it's a child the entry "dogs". What's important here is that "training 63" has no meaning if it's not associated with its ancestor context, that's why I think we should add to the entry definition that �an entry�"and can have a parent entry" (in the same way we already say that it can be a parent). The ancestor context is essential to �an entry: the string "dogs: training 63" describes the entry using the concatenated terms of the entry itself and its ancestors.I wouldn�t call��dogs: training 63� a subentry. It is an entry that has 2 levels
dogs
� � grooming, 96, 105, 192
I would call 'dogs: grooming� 72', 'dogs: grooming� 105' and 'dogs: grooming� 192' three entries, and I would consider that each of those entries is made up of a main heading, subheading and locator. (When indexers charge per entry, they are basically counting locators).
There is unfortunately no clear, generally-used definition in indexing of the word 'entry', but the NISO technical report says '...each locator, in combination with its heading, represents a single entry. An entry may contain a multi-level heading...'
If this definition isn't useful for the group, then perhaps the question could be not 'what is an entry?', but 'what atomic unit do we need to describe?'.
WRT Dave's definition below, it seems to me it could equally well be a definition of the word 'term', which we have in the terminology list, because every term in an index is able to have subheadings, locators, etc. If it was limited to level 1 headings, then it is what I would call an 'entry term', ie, the bit you encounter as you scroll down an index.
Regards,
Glenda.
I have
C) Term-only entry ?
can we have:
dogs
� � feeding, 72�
� � grooming, 96� � training, 45
Can we assume that "dogs" is an entry with no locators ? In that case we should reword "one or all of" to "none or any of" in the entry definition.
C) Entry level
+1 : it's a useful concept and wasn't clearly part of our glossary.
Romain.
On 9 mai 2012, at 05:23, David K. Ream wrote:
I went to a meeting after the conf call ended so I missed all the fun I�m glad you guys settled everything. (right).
In Bill�s example below, I wouldn�t call��dogs: training 63� a subentry. It is an entry that has 2 levels, or a main heading and a subheading.
Dictionaries refer to entries too. An entry therein is a word/term you look up and it consists of everything attached to it, such as the etymology, pronunciation (scope notes like stuff), and each sense and part of speech which are look subentries. (no locators but there are cross references sometimes.)
Here�s what I wrote up / modified after the meeting and reading the postings. It is mildly interesting to me that we have such a hard-time using English to define all this. I have consulted on SGML and XML DTDs that define index structures that can be parsed for correctness. So I know it can be done.
entry
An entry is a term that can be associated with one or all of
����������an locator list
����������a cross-reference list
����������a scope note
and can be the parent of one or more subentries. (one of the four situations must occur, or all four could.)
entry array
An entry (at any level) and all of its subentry descendants, locators, cross references and other information. (A main entry with no subentries would technically still be an entry array but only have 1 level in it, i.e., it has no children.)
main entry
A highest-level entry, i.e., it has no parent.
subentry
An entry subordinate to a main entry or subentry, i.e., it has a parent and might have children.
entry level
The depth of an entry with an entry array.� A main entry is level 1.
group
A set of main entry arrays, for example, all main entries beginning with "A" or that share some other common characteristic. It may include a group heading.
From:�epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com]�On Behalf Of�Bill Kasdorf
Sent:�Tuesday, May 08, 2012 9:34 PM
To:�epub-work...@googlegroups.com
Subject:�RE: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'�
I would just observe that �dogs: training 63� is really just a way of associating the subentry (�training 63�) with the parent entry that it�s the child of (�dogs�), or perhaps more precisely to situate it as part of the entry _array_ about �dogs.� In the context of the full index itself, you don�t need to spell out �dogs:� but if you look at the subentry in isolation, �training 63� is either ambiguous or meaningless without specifying what it�s the child of. But in this situation I think it�s perfectly appropriate to refer to �dogs: training 63� as a subentry.�Bill K
�
From:�epub-work...@googlegroups.com�[mailto:epub-work...@googlegroups.com]�On Behalf Of�Glenda Browne
Sent:�Tuesday, May 08, 2012 7:41 PM
To:�epub-work...@googlegroups.com
Subject:�[IDX] Defining 'entry' and using the word 'entry' vs 'terms'�
Hi All,
Following comments at our meeting, and thoughts about all these definitions, I think we need to clarify our definition of 'entry', and say how much it includes, and to think about when we mean 'entry' and when we mean 'term'.�
To me an entry is a locator and all of the terms that belong to it. So 'dogs� 45' is an entry, and so is 'dogs: training� 63'. (The colon indicating that a subheading follows). (A cross reference and the main heading it is attached to is also, perhaps, an entry).�
But I have seen on our mailing list the use of 'entry' to mean just the final term and its locator, eg, 'training� 63'.�
It is hard to say which is generally accepted in the indexing community. The ISO standard uses entry to mean what we call entry array; the NISO technical report definition allows for multilevel headings (ie, would call 'dogs: training� 63' an entry); LibreOffice uses the second definition (eg, 'training� 63' would be an entry); some software uses yet another definition. I think the indexing community mainly uses the NISO definition, but as Dave said we also use it casually in the context of the book, eg, 'I have an average of 10 entries per page'.�
I'm fine with either, depending on what people think is useful for the way ebooks work, but I think we need to expand the example to make it clear which one we are using.�
I also think we are using the word 'entry' in discussions when we mean 'term'. Eg, when we talked about 'child entries' we really meant 'child terms'. If we use the first definition above, it makes no sense to talk about 'entry level' or 'main entry' as the 'entry', as defined, spans all levels. If we use the second definition, and 'training� 63' is the 'entry', then it doesn't make sense to call 'dogs' its 'main entry'.�
Another message follows on heading vs entry.
Cheers,
Glenda.
entry
Term + locator OR term + cross-reference. For legacy data an entry could include a string of locators
For example, in the entry "dogs, 45", the string "dogs" is the term and the string "45" is the locator
term
Character string, representing the indexable item -- e.g., a name, place, concept, topic, or any one of an almost infinite number of things.
--Glenda BrowneIndexer, Writer, TeacherMember of the IDPF EPUB Indexes Working GroupAuthor of The Indexing Companion Workbook: Book Indexinghttp://www.webindexing.bizhttp://en-gb.facebook.com/pages/The-Indexing-Companion-Book-Indexing-Workbook/82315763536
David K. Ream
Glenda is correct that indexers sometimes use subentry and subsubentry (etc.) rather than saying level 2 entry, level 3 entry, etc.
But subentry can be used in a general sense too meaning a subentry under any level – that is in a relative way. So I think if we define that clearly we aren’t contravening any world-wide convention.
As to the comment about reword [ "one or all of" to "none or any of" ], I did give thought to that and don’t have a major object. I was trying to use “can be associated” to indirectly infer that none is a possibility. It has to be phrased only so that this is not allowed:
Candles, 45
Canines
Dogs
Poodles, 33
Samoyeds, 72
An entry cannot be just a term.
David K. Ream
Glenda per my latest post I disagree. In some context subheading/subentry is used in a relative sense not always in the absolute. Again for our purposes we can certainly say that I think.
Also regarding entry and its semantic fuzziness, I agree as you note below that indexers would not call dogs an entry by itself and it is part of all three. But I don’t know how to resolve this dilemma (dictionary puns are allowed, right?). We need a “term” that means what we say it means and nothing more. So either we repurpose entry in a specific meaning or come up with a new term. In my comment about dictionaries I tried to set the groundwork for why I defined it as I did. I think in a sense what we actually mean is “entry point”. I do disagree that Dogs doesn’t lead to anything, it leads to its subentries.
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Glenda Browne
Sent: Wednesday, May 09, 2012 9:30 AM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Hi Romain,
Sorry, if I said a subheading is a level 1 entry I meant level 2. To an indexer a subheading is always directly under a main heading. If it is the next level down (ie level 3 entry) we call it a subsubheading. But if it doesn't matter as far as programming goes, then I'm fine with this. If we define only main headings and subheadings, it seems to me that 'subheading' will be synonymous with 'child entry'. Subsubheading could be described by combining 'subheading' with a level number if its level was crucial.
More comments inline below...
On 9/05/2012 10:40 PM, Romain Deltour wrote:
I mostly agree with Dave's definitions below, but I think some points still needs to be clarified:
A) Subentries
Glenda said that in the indexing world a "subentry" has an absolute position: it is a level 1 entry. This is conflicting with the definition below and needs to be clarified. I would personally vote for "subentry" meaning "an entry that has a parent, i.e. an entry that is not a main entry" (=Dave's definition) rather than the absolute "level 1 entry", but if this is conflicting with the indexers lingo we might want to simply ditch the word "subentry".
B) Entry ancestors context
Dave wrote:
I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels
I disagree. "dogs: training 63" is a subentry as it's a child the entry "dogs". What's important here is that "training 63" has no meaning if it's not associated with its ancestor context, that's why I think we should add to the entry definition that an entry "and can have a parent entry" (in the same way we already say that it can be a parent). The ancestor context is essential to an entry: the string "dogs: training 63" describes the entry using the concatenated terms of the entry itself and its ancestors.
I think this example below (and what I think are Bill's comments above, which I just noticed as new content) comes back to the difference between a term and an entry. 'dogs' in the entry array below is a term, but in my usage it is not an entry. To me an entry is everything that expresses the content that a locator will take you to. So 'dogs' would be part of three entries - 'dogs: feeding 72', 'dogs: grooming 72', and 'dogs: training 72. 'Dogs' is not an entry because it doesn't lead to anything. If the entry array was:
dogs
feeding, 72
grooming, 96, 105, 192
training, 45
I would call 'dogs: grooming 72', 'dogs: grooming 105' and 'dogs: grooming 192' three entries, and I would consider that each of those entries is made up of a main heading, subheading and locator. (When indexers charge per entry, they are basically counting locators).
There is unfortunately no clear, generally-used definition in indexing of the word 'entry', but the NISO technical report says '...each locator, in combination with its heading, represents a single entry. An entry may contain a multi-level heading...'
If this definition isn't useful for the group, then perhaps the question could be not 'what is an entry?', but 'what atomic unit do we need to describe?'.
WRT Dave's definition below, it seems to me it could equally well be a definition of the word 'term', which we have in the terminology list, because every term in an index is able to have subheadings, locators, etc. If it was limited to level 1 headings, then it is what I would call an 'entry term', ie, the bit you encounter as you scroll down an index.
Regards,
Glenda.
I have
C) Term-only entry ?
can we have:
dogs
feeding, 72
grooming, 96
training, 45
Can we assume that "dogs" is an entry with no locators ? In that case we should reword "one or all of" to "none or any of" in the entry definition.
C) Entry level
+1 : it's a useful concept and wasn't clearly part of our glossary.
Romain.
On 9 mai 2012, at 05:23, David K. Ream wrote:
I went to a meeting after the conf call ended so I missed all the fun I’m glad you guys settled everything. (right).
In Bill’s example below, I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels, or a main heading and a subheading.
Dictionaries refer to entries too. An entry therein is a word/term you look up and it consists of everything attached to it, such as the etymology, pronunciation (scope notes like stuff), and each sense and part of speech which are look subentries. (no locators but there are cross references sometimes.)
Here’s what I wrote up / modified after the meeting and reading the postings. It is mildly interesting to me that we have such a hard-time using English to define all this. I have consulted on SGML and XML DTDs that define index structures that can be parsed for correctness. So I know it can be done.
entry
An entry is a term that can be associated with one or all of
· an locator list
· a cross-reference list
· a scope note
and can be the parent of one or more subentries. (one of the four situations must occur, or all four could.)
entry array
An entry (at any level) and all of its subentry descendants, locators, cross references and other information. (A main entry with no subentries would technically still be an entry array but only have 1 level in it, i.e., it has no children.)
main entry
A highest-level entry, i.e., it has no parent.
subentry
An entry subordinate to a main entry or subentry, i.e., it has a parent and might have children.
entry level
The depth of an entry with an entry array. A main entry is level 1.
group
A set of main entry arrays, for example, all main entries beginning with "A" or that share some other common characteristic. It may include a group heading.
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Bill Kasdorf
Sent: Tuesday, May 08, 2012 9:34 PM
To: epub-work...@googlegroups.com
Subject: RE: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
I would just observe that “dogs: training 63” is really just a way of associating the subentry (“training 63”) with the parent entry that it’s the child of (“dogs”), or perhaps more precisely to situate it as part of the entry _array_ about “dogs.” In the context of the full index itself, you don’t need to spell out “dogs:” but if you look at the subentry in isolation, “training 63” is either ambiguous or meaningless without specifying what it’s the child of. But in this situation I think it’s perfectly appropriate to refer to “dogs: training 63” as a subentry.—Bill K
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Glenda Browne
Sent: Tuesday, May 08, 2012 7:41 PM
To: epub-work...@googlegroups.com
Subject: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Hi All,
Following comments at our meeting, and thoughts about all these definitions, I think we need to clarify our definition of 'entry', and say how much it includes, and to think about when we mean 'entry' and when we mean 'term'.
To me an entry is a locator and all of the terms that belong to it. So 'dogs 45' is an entry, and so is 'dogs: training 63'. (The colon indicating that a subheading follows). (A cross reference and the main heading it is attached to is also, perhaps, an entry).
But I have seen on our mailing list the use of 'entry' to mean just the final term and its locator, eg, 'training 63'.
It is hard to say which is generally accepted in the indexing community. The ISO standard uses entry to mean what we call entry array; the NISO technical report definition allows for multilevel headings (ie, would call 'dogs: training 63' an entry); LibreOffice uses the second definition (eg, 'training 63' would be an entry); some software uses yet another definition. I think the indexing community mainly uses the NISO definition, but as Dave said we also use it casually in the context of the book, eg, 'I have an average of 10 entries per page'.
I'm fine with either, depending on what people think is useful for the way ebooks work, but I think we need to expand the example to make it clear which one we are using.
I also think we are using the word 'entry' in discussions when we mean 'term'. Eg, when we talked about 'child entries' we really meant 'child terms'. If we use the first definition above, it makes no sense to talk about 'entry level' or 'main entry' as the 'entry', as defined, spans all levels. If we use the second definition, and 'training 63' is the 'entry', then it doesn't make sense to call 'dogs' its 'main entry'.
Another message follows on heading vs entry.
Cheers,
Glenda.
entry
Term + locator OR term + cross-reference. For legacy data an entry could include a string of locators
For example, in the entry "dogs, 45", the string "dogs" is the term and the string "45" is the locator
term
Character string, representing the indexable item -- e.g., a name, place, concept, topic, or any one of an almost infinite number of things.
--
Glenda Browne
Indexer, Writer, Teacher
Member of the IDPF EPUB Indexes Working Group
Author of The Indexing Companion Workbook: Book Indexing
http://www.webindexing.biz
http://en-gb.facebook.com/pages/The-Indexing-Companion-Book-Indexing-Workbook/82315763536
David K. Ream
I would also state that I’m all for using terminology from standards that is accepted.
When the standards all don’t agree, the community doesn’t agree, and the terminology doesn’t work for us, then we need to specify what we mean for our purposes.
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Glenda Browne
Sent: Wednesday, May 09, 2012 9:30 AM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Hi Romain,
Sorry, if I said a subheading is a level 1 entry I meant level 2. To an indexer a subheading is always directly under a main heading. If it is the next level down (ie level 3 entry) we call it a subsubheading. But if it doesn't matter as far as programming goes, then I'm fine with this. If we define only main headings and subheadings, it seems to me that 'subheading' will be synonymous with 'child entry'. Subsubheading could be described by combining 'subheading' with a level number if its level was crucial.
More comments inline below...
On 9/05/2012 10:40 PM, Romain Deltour wrote:
I mostly agree with Dave's definitions below, but I think some points still needs to be clarified:
A) Subentries
Glenda said that in the indexing world a "subentry" has an absolute position: it is a level 1 entry. This is conflicting with the definition below and needs to be clarified. I would personally vote for "subentry" meaning "an entry that has a parent, i.e. an entry that is not a main entry" (=Dave's definition) rather than the absolute "level 1 entry", but if this is conflicting with the indexers lingo we might want to simply ditch the word "subentry".
B) Entry ancestors context
Dave wrote:
I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels
I disagree. "dogs: training 63" is a subentry as it's a child the entry "dogs". What's important here is that "training 63" has no meaning if it's not associated with its ancestor context, that's why I think we should add to the entry definition that an entry "and can have a parent entry" (in the same way we already say that it can be a parent). The ancestor context is essential to an entry: the string "dogs: training 63" describes the entry using the concatenated terms of the entry itself and its ancestors.
I think this example below (and what I think are Bill's comments above, which I just noticed as new content) comes back to the difference between a term and an entry. 'dogs' in the entry array below is a term, but in my usage it is not an entry. To me an entry is everything that expresses the content that a locator will take you to. So 'dogs' would be part of three entries - 'dogs: feeding 72', 'dogs: grooming 72', and 'dogs: training 72. 'Dogs' is not an entry because it doesn't lead to anything. If the entry array was:
dogs
feeding, 72
grooming, 96, 105, 192
training, 45
I would call 'dogs: grooming 72', 'dogs: grooming 105' and 'dogs: grooming 192' three entries, and I would consider that each of those entries is made up of a main heading, subheading and locator. (When indexers charge per entry, they are basically counting locators).
There is unfortunately no clear, generally-used definition in indexing of the word 'entry', but the NISO technical report says '...each locator, in combination with its heading, represents a single entry. An entry may contain a multi-level heading...'
If this definition isn't useful for the group, then perhaps the question could be not 'what is an entry?', but 'what atomic unit do we need to describe?'.
WRT Dave's definition below, it seems to me it could equally well be a definition of the word 'term', which we have in the terminology list, because every term in an index is able to have subheadings, locators, etc. If it was limited to level 1 headings, then it is what I would call an 'entry term', ie, the bit you encounter as you scroll down an index.
Regards,
Glenda.
I have
C) Term-only entry ?
can we have:
dogs
feeding, 72
grooming, 96
training, 45
Can we assume that "dogs" is an entry with no locators ? In that case we should reword "one or all of" to "none or any of" in the entry definition.
C) Entry level
+1 : it's a useful concept and wasn't clearly part of our glossary.
Romain.
On 9 mai 2012, at 05:23, David K. Ream wrote:
I went to a meeting after the conf call ended so I missed all the fun I’m glad you guys settled everything. (right).
In Bill’s example below, I wouldn’t call “dogs: training 63” a subentry. It is an entry that has 2 levels, or a main heading and a subheading.
Dictionaries refer to entries too. An entry therein is a word/term you look up and it consists of everything attached to it, such as the etymology, pronunciation (scope notes like stuff), and each sense and part of speech which are look subentries. (no locators but there are cross references sometimes.)
Here’s what I wrote up / modified after the meeting and reading the postings. It is mildly interesting to me that we have such a hard-time using English to define all this. I have consulted on SGML and XML DTDs that define index structures that can be parsed for correctness. So I know it can be done.
entry
An entry is a term that can be associated with one or all of
· an locator list
· a cross-reference list
· a scope note
and can be the parent of one or more subentries. (one of the four situations must occur, or all four could.)
entry array
An entry (at any level) and all of its subentry descendants, locators, cross references and other information. (A main entry with no subentries would technically still be an entry array but only have 1 level in it, i.e., it has no children.)
main entry
A highest-level entry, i.e., it has no parent.
subentry
An entry subordinate to a main entry or subentry, i.e., it has a parent and might have children.
entry level
The depth of an entry with an entry array. A main entry is level 1.
group
A set of main entry arrays, for example, all main entries beginning with "A" or that share some other common characteristic. It may include a group heading.
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Bill Kasdorf
Sent: Tuesday, May 08, 2012 9:34 PM
To: epub-work...@googlegroups.com
Subject: RE: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
I would just observe that “dogs: training 63” is really just a way of associating the subentry (“training 63”) with the parent entry that it’s the child of (“dogs”), or perhaps more precisely to situate it as part of the entry _array_ about “dogs.” In the context of the full index itself, you don’t need to spell out “dogs:” but if you look at the subentry in isolation, “training 63” is either ambiguous or meaningless without specifying what it’s the child of. But in this situation I think it’s perfectly appropriate to refer to “dogs: training 63” as a subentry.—Bill K
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Glenda Browne
Sent: Tuesday, May 08, 2012 7:41 PM
To: epub-work...@googlegroups.com
Subject: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Hi All,
Following comments at our meeting, and thoughts about all these definitions, I think we need to clarify our definition of 'entry', and say how much it includes, and to think about when we mean 'entry' and when we mean 'term'.
To me an entry is a locator and all of the terms that belong to it. So 'dogs 45' is an entry, and so is 'dogs: training 63'. (The colon indicating that a subheading follows). (A cross reference and the main heading it is attached to is also, perhaps, an entry).
But I have seen on our mailing list the use of 'entry' to mean just the final term and its locator, eg, 'training 63'.
It is hard to say which is generally accepted in the indexing community. The ISO standard uses entry to mean what we call entry array; the NISO technical report definition allows for multilevel headings (ie, would call 'dogs: training 63' an entry); LibreOffice uses the second definition (eg, 'training 63' would be an entry); some software uses yet another definition. I think the indexing community mainly uses the NISO definition, but as Dave said we also use it casually in the context of the book, eg, 'I have an average of 10 entries per page'.
I'm fine with either, depending on what people think is useful for the way ebooks work, but I think we need to expand the example to make it clear which one we are using.
I also think we are using the word 'entry' in discussions when we mean 'term'. Eg, when we talked about 'child entries' we really meant 'child terms'. If we use the first definition above, it makes no sense to talk about 'entry level' or 'main entry' as the 'entry', as defined, spans all levels. If we use the second definition, and 'training 63' is the 'entry', then it doesn't make sense to call 'dogs' its 'main entry'.
Another message follows on heading vs entry.
Cheers,
Glenda.
entry
Term + locator OR term + cross-reference. For legacy data an entry could include a string of locators
For example, in the entry "dogs, 45", the string "dogs" is the term and the string "45" is the locator
term
Character string, representing the indexable item -- e.g., a name, place, concept, topic, or any one of an almost infinite number of things.
--
Glenda Browne
Indexer, Writer, Teacher
Member of the IDPF EPUB Indexes Working Group
Author of The Indexing Companion Workbook: Book Indexing
http://www.webindexing.biz
http://en-gb.facebook.com/pages/The-Indexing-Companion-Book-Indexing-Workbook/82315763536
mrot...@twcny.rr.com
entry: (1) term + locator (2) term + cross reference or (3) term alone, IF AND ONLY IF it has one or more child entries.
Robert Bolick
David K. Ream
Canines is just a term, no locator, no xref, no subentries.
-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of mrot...@twcny.rr.com
Sent: Wednesday, May 09, 2012 11:51 AM
To: epub-work...@googlegroups.com
Cc: David K. Ream
Subject: RE: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Robert Bolick
David K. Ream
I am saying that Canines should not be allowed.
It is meaningless (or a mistake) in an index for a entry to be only a term and nothing attached to it or subordinate to it.
mrot...@twcny.rr.com
---- "David K. Ream" <dave...@levtechinc.com> wrote:
> I am saying that Canines should not be allowed.
>
> It is meaningless (or a mistake) in an index for a entry to be only a term
> and nothing attached to it or subordinate to it.
>
>
>
>
>
>
David K. Ream
mrot...@twcny.rr.com
Michele
Robert Bolick
Sent from Gmail Mobile
Lee Passey
An 'entry' (or whatever we agree to call it) is /not/ an atomic element;
it is a compound element composed of A. a 'term' (which is an atomic
element) and B. one or both of the following compound elements:
1. a list of compound 'locator' elements, which can point to locations
in the text or locations in the index ("see" and "see also");
2. a single 'entry array'.
An 'entry array' is a compound element composed of an
array/list/set/table of one or more 'entries' (no more complex
definition is needed).
An 'entry' must have one, and only one, 'term.'
A 'simple entry' is an entry having a 'term' and a list of at least one
compound 'locator'.
A 'complex entry' is an entry having a 'term', an 'entry array', and an
optional list of one or more compound 'locators.'
Consider the following enhanced example:
dogs
feeding, 72
large-breed concerns, 74
grooming
short-hairs, 96
long-hairs, 96-97
training, 45, 51-55
border-collies, 48
devices for, 289
This examples contains five simple entries ('term'::{'locator' list}):
1. large-breed concerns::{74}
2. short-hairs::{96}
3. long-hairs::{96-97}
4. border-collies::{48}
5. devices for::{289}
(I used the "::" delimiter to segregate 'term' and 'locator' as it is
unlikely you will ever actually see "::" in an index, unless you are
indexing a book on C++ programming).
These five simple entries are grouped into three entry arrays:
1. {large-breed concerns::74}
2. {short-hairs::96, long-hairs::96-97}
3. {border-collies::48, devices for::289}
These three entry arrays are used to compose three complex entries:
1. feeding::{ 72, {large-breed concerns::74} }
2. grooming::{ {short-hairs::96, long-hairs::96-97} }
3. training::{ 45, 51-55, {border-collies::48, devices for::289} }
The three complex entries are combined into a single 'entry array' to
construct the main entry:
dogs::{{feeding::{ 72,
{large-breed concerns::74}}},
{grooming::{ short-hairs::96,
long-hairs::96-97}},
{training::{ 45,
51-55,
{border-collies::48,
devices for::289} }}}
In this case, we have a complex entry where "dogs" is the term, and the
association is a list containing one 'entry array'. The first 'entry' in
the (single) 'entry array' has a term of "feeding" and a list of one
compound 'locator' and one 'entry array' containing a single simple entry.
The second 'entry' in the main 'entry array' is a complex entry having
the term "grooming" and containing a single 'entry array' composed of
two simple 'entries.'
The third (last) 'entry' in the main 'entry array' is a complex entry
having the term of "training" and a list of two compound 'locators' and
a single 'entry array' containing two simple 'entries.'
In the above example, the "::" delimiter represents a parent/child
relationship. For purposes of discussion it should be possible to refer
to the locator "48" as having a term of
"dogs::training::border-collies", which notation would carry the implied
generational chain, but this abbreviated notation should not be confused
with the full structure above.
(When we become interested in implementation issues, let me know and
I'll provide a few alternative XML implementations of the above example.
Someone who speaks BNF should also be able to translate this example
into BNF.)
On a related note, Mr. Ream's comments about "semantic fuzziness" is
well-taken, although I would have used the phrase "semantic baggage"
instead. As Ms. Browne has pointed out, the "generally accepted" meaning
for the word entry differs depending on who is doing the accepting
("That word you keep using; I do not think it means what you think it
means." -- Inigo Montoya).
When creating a specification, it is important that a word have one, and
only one meaning. It does not even need to be the "generally accepted"
meaning, so long as the meaning is clear within the context of the
specification (or at least as clear as we error-prone humans can make
it). If the consensus is that an "entry" is a "term" plus something that
helps you locate the target, then we should all agree that that will be
the meaning; if someone uses the word "entry" to mean the word which is
the entry point into an 'entry', the proper response should not be to
continue to misuse the word, but to say "when you said 'entry' it is
obvious that you meant the word 'term', and given that change..."
Sometimes neologisms are a better choice for a specification vocabulary,
because they carry no semantic baggage that people are loathe to discard.
A particular sore spot for me is the word 'locator.' Some use the word
to mean "that alpha-numeric word or phrase presented to the end user
designed to allow her to find a location in the text." Others have used
the word to mean "a machine-parsable phrase which will allow software to
navigate to a specific point in the content." Still others have used the
word to mean "a complex element combining end-user viewable content,
machine-parsable linkage, and other presentational and semantic
(decoration) attributes." Most of the time, which of these meanings is
intended is not clear from the context. (FWIW, in this post I have used
the word 'locator' in the sense of a compound element.)
It seems to me that whatever data that serves to find a location in the
content and is attached to a 'term' in an 'entry' and which is not an
'entry array' has at least five components:
1. User viewable text (required, atomic)
2. Machine usable linkage (required, atomic)
3. Presentation hints (css, optional, compound)
4. Semantic attributes ('decoration', optional, compound)
5. Scope notes or glosses (optional, possibly compound)
Every one of these things needs a unique and unambiguous term (as
opposed to the term 'term'), and a term is required to represent the
complex element which is constructed from these atomic components.
On 5/9/2012 6:40 AM, Romain Deltour wrote:
> I mostly agree with Dave's definitions below, but I think some points
> still needs to be clarified:
>
>
> A) Subentries
>
> Glenda said that in the indexing world a "subentry" has an absolute
> position: it is a level 1 entry. This is conflicting with the definition
> below and needs to be clarified. I would personally vote for "subentry"
> meaning "an entry that has a parent, i.e. an entry that is not a main
> entry" (=Dave's definition) rather than the absolute "level 1 entry",
> but if this is conflicting with the indexers lingo we might want to
> simply ditch the word "subentry".
>
> B) Entry ancestors context
>
> Dave wrote:
>>
Glenda Browne
In your definition, I'm assuming you're using 'term' to include main
entries and subentries, and that therefore (1) could include a subentry
plus locator and (2) could include a subentry plus cross reference.
Leaving out (3) for now, that would always make an entry the last two
bits of an 'index line' (for want of a better word).
wrt (3), I think 'dogs' only seems to standalone because of the
presentation we have used in the examples (which is used in most
displayed indexes, but is not essential). In a logical sense, the
entries below are really:
dogs:poodles::33
dogs:samoyeds::72
and 'dogs' has no meaning outside these complex groups. In theory, a
reading device could display the index as in the two lines above without
'dogs' standing out at all, so making 'dogs' a special case seems
unnecessary. It is still a main entry, but not a special case of 'entry'
based only on presentation.
If we use your definition, then I feel we are still missing a definition
for what I called an 'index line' above. We will sometimes need to talk
about a locator and all of the terms that come before it. That is, what
do we call 'dogs:poodles::33'? We would need that if, eg, an in-context
index pulled out all of the 'index lines' that contained their search
term. It would have to extract the whole 'index line' for the
information they provide to make any sense. We would also use that
definition when we want a broader term to show in the 'hover' over a
child term.
Your definition also seems to differ from Dave's original one, in that
his (I think) said that an entry was a thing that could have a locator,
but didn't say that entry included the locator. As I slept on this last
night I was thinking that Dave's definition was of entry as a broader
term of main entry and subentry.
(Terminology question: does 'antecedents' only refer to parts that are
of the same type, or could I say that 'samoyeds' and 'dogs' are
antecedents of the locator 72?) (Was the example 'samoyeds' made up of a
dog lover who is also a good speller? I have to keep making sure I get
it right ; ) )
Cheers,
Glenda.
Glenda Browne
My response on Michele's email also covers some of this.
The Charter document uses the term 'entry term', so perhaps that is worth adding. As I understand both yours and Michele's definitions of entry, they are different to the four existing definitions of entry that I know of. So if we could find a good term that specifically describes what we mean (and why it is an important concept) that would be good.
If the word 'entry' is used in the Dictionaries spec, does it matter if we also use it for Indexes?
Cheers,
Glenda
Romain Deltour
>
> Leaving out (3) for now, that would always make an entry the last two bits of an 'index line' (for want of a better word).
>
> wrt (3), I think 'dogs' only seems to standalone because of the presentation we have used in the examples (which is used in most displayed indexes, but is not essential). In a logical sense, the entries below are really:
>
> dogs:poodles::33
> dogs:samoyeds::72
>
> and 'dogs' has no meaning outside these complex groups. In theory, a reading device could display the index as in the two lines above without 'dogs' standing out at all, so making 'dogs' a special case seems unnecessary. It is still a main entry, but not a special case of 'entry' based only on presentation.
>
> If we use your definition, then I feel we are still missing a definition for what I called an 'index line' above. We will sometimes need to talk about a locator and all of the terms that come before it. That is, what do we call 'dogs:poodles::33'? We would need that if, eg, an in-context index pulled out all of the 'index lines' that contained their search term. It would have to extract the whole 'index line' for the information they provide to make any sense. We would also use that definition when we want a broader term to show in the 'hover' over a child term.
>
> Your definition also seems to differ from Dave's original one, in that his (I think) said that an entry was a thing that could have a locator, but didn't say that entry included the locator. As I slept on this last night I was thinking that Dave's definition was of entry as a broader term of main entry and subentry.
>
> (Terminology question: does 'antecedents' only refer to parts that are of the same type, or could I say that 'samoyeds' and 'dogs' are antecedents of the locator 72?) (Was the example 'samoyeds' made up of a dog lover who is also a good speller? I have to keep making sure I get it right ; ) )
Romain.
MicheleR
> Michele,
>
> In your definition, I'm assuming you're using 'term' to include main entries
indexable thing (name, concept, whatever), sans locator or references or
anything else.
> wrt (3), I think 'dogs' only seems to standalone because of the presentation we
> have used in the examples (which is used in most displayed indexes, but is not
> essential). In a logical sense, the entries below are really:
>
> dogs:poodles::33
> dogs:samoyeds::72
>
> and 'dogs' has no meaning outside these complex groups.
examples, "dog" is the main entry and poodles and samoyeds are subentries.
> If we use your definition, then I feel we are still missing a definition for
> what I called an 'index line' above. We will sometimes need to talk about a
> locator and all of the terms that come before it. That is, what do we call
> 'dogs:poodles::33'?
Atomically speaking:
"dogs" and "poodles" are both terms.
"33" is a locator.
Relatively speaking:
"dogs" is also an entry, per definition 3. It is a parent entry to "poodles."
"poodles, 33" is also and entry, per definition 1. It is a child entry to "dogs."
Absolutely speaking"
"dogs" is a main entry.
"poodles" is a subentry.
Michele
--
+---+---+---+---+---+---+---+---+---+---+---+---+
I object to intellect without discipline;
I object to power without constructive purpose.
-- Spock, "The Squire of Gothos"
+---+---+---+---+---+---+---+---+---+---+---+---+
MicheleR
>
> My understanding is that none of the (1)(2)(3) definitions of
> "an entry" include the subentries of this entry. In other words,
> an entry doesn't "contain" its subentries (in the tree/graph
> theory, an entry is just the node, not the entire subtree).
were using "entry array".
>> dogs:poodles::33
>> dogs:samoyeds::72
>>
>> and 'dogs' has no meaning outside these complex groups
> one-line representation of dogs:poodles and dogs:samoyeds
> does not change the fact that "poodles" and "samoyeds" are
> identified as specific items of the more generic "dogs"
> group ; it makes "dogs" a logical entry of its own (in
> this case, it is even a "main entry" as it is top-level).
>
> My understanding of Dave's definition is that the entry
> *does* include the locator(s) (or xref or scope note).
entry is either (1) term + locator or (2) term + cross-reference or (3) term
alone IF the term is a main entry AND has at least one child entry.
> I assume by "antecedents" you mean "ancestors". If the entry
> actually contains the locators as mentioned above, then "dogs"
> is an ancestor of "dogs:samoyeds:72", but "72" itself is not
> an entry, hence is not part of the parent/child tree and has
> no ancestors per se.
Michele
--
++++++++++++++++++++++++++
Such is the irresistible nature of
truth that all it asks, and all it wants,
is the liberty of appearing.
-- Thomas Paine
++++++++++++++++++++++++++
David K. Ream
to entry. I'm leaning towards entry and entry term.
Again, I'm reflecting on the dictionary analogy. So a main entry is like a
word in a dictionary. It is the top level "concept" that is being browsed.
Everything else is fruit of the main entry. An entry (main or sub) thus is
an entry term with optionally a scope note, a locator list, a cross ref
list, child entry/entries.
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MicheleR
Sent: Wednesday, May 09, 2012 7:19 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
David K. Ream
Yes it is sometimes instructive to read what was already thought out. I think entry term helps unfuzzify entry as talking about the “heading” not entry as all the headings plus locator or xref.
As to the in-context index, if we structure the index data properly, providing clarity on how to walk up the tree of parents, the in-context entries are derivable. For performance purposes, allowing an in-context index is probably useful.
Dave
MicheleR
> I think I'm in favor of ditching "entry array" is too confusing with respect
> to entry. I'm leaning towards entry and entry term.
child entries, other than saying "an entry and all its child entries." I'm OK
with that if everyone else is; it certainly simplifies things to go back to
using parent/child relators rather than inventing new terms :)
As to "entry term" I'm not sure what is meant by that. I had thought we were
sort of converging on the definition of "entry" as follows:
(1) term + locator OR
(2) term + cross reference OR
(3) term alone, IF the term is a main entry AND has at least one child entry
Are we proposing to replace the word "term" with the phrase "entry term"
throughout the above? If so, I guess I would just ask, "Do we think the extra
word is necessary?" (I prefer fewer words whenever possible!)
Michele
--
Always deny the apocalypse.
You'll usually be right, and when you're wrong,
no one will be left to say, 'I told you so.'
David K. Ream
herein in the ISO sense per Glenda's email.
Boxers, 59
Dogs, 33. See also specific breeds.
large-breed concerns, 74
grooming
short-hairs, 96
long-hairs, 96-97
Bassett, 27
Viszlas, 121
Weimaraners, 203
There are three main entries with the entry terms Boxers, Dogs, Hounds. Each
is an entry as is feeding, large-bread concerns, grooming, etc. These latter
are subentries. I don't see the need for an atomic element entry array
because each entry, main or sub, "carries" along with it everything referred
to by it (locators & cross refs) or subordinate to it deeper subentries.
The entry level (1-n) would provide information necessary for
display/rendering and navigation of parents and children.
I'm not wedded to entry term v. term but I think it is helpful when trying
to use the word term in the general English sense during discussion, like
saying index body rather than simply body.
This begs the question of what to call an entry meaning the atomic unit of
an index:
(Boxers::59)
(Dogs:grooming:short-hairs::96)
(Hounds:Weimaraners::203)
Etc.
atomic entry? entry singularity? discrete entry?
Do we need this? It doesn't seem so for the chapter-like index. For the
in-context (nee reverse) index, atomic entries need to be "extracted"
possibly from the chapter-like index but when displayed to the user they
could be displayed as they are in the chapter-like index.
Remember that only indexers use entry in this sense when entering and
editing them. The rest of the world only deals with entries as displayed in
indented or run-in or possibly tabular formats. Even so a singular entry is
still expressed as a main, with/out subs, and a locator or cross ref the
same elements as I describe above but restricted to a monotonic tree not one
with multiple branches.
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MicheleR
Sent: Wednesday, May 09, 2012 9:15 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Romain Deltour
It is still useful to have both a term to describe an entry without its children (e.g. "dogs:feeding:36") and a term to describe an entry with its descendants subtree.
We need to keep in mind that the terms defined in our glossary do not have to be directly match an XML/XHTML element in our structural representation of the index.
Romain.
Romain Deltour
If we decide that an "entry" contains its child entries, I wouldn't use "[qualifier] entry" here, it would be too confusing.
I would either use "entry [component name]" like "entry item" or "entry topic" (suggestions welcome), or a totally different term like "topic" or "topic treatment".
Romain.
Glenda Browne
not the locator that goes with it.
atomic entry? entry singularity? discrete entry? - I like these ideas as starting points. It is hard to define this. While I think entry is used to mean many things, in my experience the 'atomic unit' of an index is only ever called an 'entry', so there aren't existing alternatives to consider (and making a new one up is very difficult). 'Entry unit' or 'Index unit' or 'Index term unit' or 'Composite index entry' come to mind (I don't think they're great, but throw them in for discussion).
Cheers,
Glenda.
On 10/05/2012 11:46 AM, David K. Ream wrote:
> Let's try it with this augmented, recent example below. I'm using entry
> herein in the ISO sense per Glenda's email.
>
> Boxers, 59
> Dogs, 33. See also specific breeds.
> feeding, 72
> large-breed concerns, 74
> grooming
> short-hairs, 96
> long-hairs, 96-97
> Hounds
> Bassett, 27
> Viszlas, 121
> Weimaraners, 203
>
> There are three main entries with the entry terms Boxers, Dogs, Hounds. Each
> is an entry as is feeding, large-bread concerns, grooming, etc. These latter
> are subentries. I don't see the need for an atomic element entry array
> because each entry, main or sub, "carries" along with it everything referred
Glenda Browne
I agree with you that this wasn't meant to include children. What I
wondered was whether a subentry could be the starting point, and I think
further discussion suggested yes, because 'term' encompasses main and
subentries.
Glenda.
On 10/05/2012 8:40 AM, Romain Deltour wrote:
>> In your definition, I'm assuming you're using 'term' to include main entries and subentries, and that therefore (1) could include a subentry plus locator and (2) could include a subentry plus cross reference.
> My understanding is that none of the (1)(2)(3) definitions of "an entry" include the subentries of this entry. In other words, an entry doesn't "contain" its subentries (in the tree/graph theory, an entry is just the node, not the entire subtree).
>
Robert Bolick
Glenda Browne
can't see how they could be merged. To me they are both fundamental
concepts to the way indexes are structured, and I think it would be
useful to define them, even if in the final product entry arrays are
derived by the system.
If we define 'entry array', but don't use that term, I like the idea of
going away from the word 'entry' altogether. As I read them,
"entry item" or "entry topic" could both mean either entry array or entry line (eg, "dogs:feeding:36").
One option for entry array might be 'topic block'. I have seen the term 'entry block' suggested elwsewhere (by someone who thought array has an incompatible meaning, as also mentioned by someone on this list). The word 'block' suggests a chunk, whereas something like 'treatment' again could be either the entry array or the entry line.
To me the other crucial parts of the topical part of an index (as opposed to locators etc) are main entry and subentry (which includes subsubentries).
I don't relate to the definition of 'entry' we have been considering. It seems to mix many different things - a main entry that has subentries that have locators; a main entry that has locators of its own; a main entry with a see cross reference; a subentry with locators; potentially a subentry with no locators but with subsubentries of their own...
If 'entry' was defined as main entries and subentries without locators that would be clearer, but this is pretty much the same as the definition of 'term'.
If 'entry term' was defined as the first term you encounter as you browse an index that would include the main entries with and without locators, but would exclude the subentries. If EPUB was determining filing order, then entry term would be crucial. But as publishers are providing the filing order, it is less important.
Another possibly significant concept is the last term before a locator. This is part of the definition of 'entry' which we have been considering, but isn't all of it.
Glenda
MicheleR
>
> "entry item" or "entry topic" could both mean either entry array or entry line
> (eg, "dogs:feeding:36").
possibly what is confusing things? When legacy indexes are converted to epub
format, the main entry does not get repeated for every subentry (unless you are
suggesting that that should be part of our spec?). In other words, you call
"dogs:feeding:36" an entry line, but in an indented layout that would be TWO lines:
dogs
feeding, 36
>
> I don't relate to the definition of 'entry' we have been considering. It seems
> to mix many different things -
> a main entry that has subentries
> a main entry with its cross reference
> a subentry with its locators
> a subentry that has subsubentries
I've reformatted your examples slightly for ease of comparison, but yes, as
currently drafted all those would be "entries". (Note the difference between
"with" and "that has". An "entry" does not /include/ its subentries.)
Semantically speaking, what they all have in common is that they are the next
semantic chunk above "term" (or "topic" if we prefer to go that way) and
"locator", but the next smallest below an "entry array" (or "topic block" if we
prefer to go that way). And actually the last two are identical to the second
and third, just located elsewhere in the tree (i.e., they have a parent entry).
In an index with indented layout, each of these would be an "entry line" -- I'd
actually be fine with using that, if that's what we decide on. Though given
your example above we may have different definitions of "entry line" as well ;)
>
> If 'entry' was defined as main entries and subentries without locators that
> would be clearer, but this is pretty much the same as the definition of 'term'.
chunk above term/locator/xref, hence the inclusion of one of those three options
(locator, xref, or "has children").
> If 'entry term' was defined as the first term you encounter as you browse an
> index that would include the main entries with and without locators, but would
> exclude the subentries. If EPUB was determining filing order, then entry term
> would be crucial. But as publishers are providing the filing order, it is less
> important.
> Another possibly significant concept is the last term before a locator. This is
> part of the definition of 'entry' which we have been considering, but isn't all
> of it.
term/topic no matter where it occurs. There's nothing functionally different
about them. If the reading system or its CSS needed to identify the first or
last one for some reason, it could do in terms of parents/children. The first
term would be the one in any entry with out a parent entry, the last term would
be the one any entry without child entries.
In XML terms I think you'd call that last entry a "leaf" since the tree
structure terminates at that point. But again, functionally speaking, I'm not
sure that's important.
Michele
--
----+----+----+----+----+----+----+----+----+----+----+----+
I am not going to question your opinions.
I am not going to meddle with your belief.
I am not going to dictate to you mine.
All that I say is, examine, inquire. Look
into the nature of things. Search out the
grounds of your opinions, the for and the
against. Know why you believe, understand
what you believe, and possess a reason
for the faith that is in you.
-- Frances Wright, "Divisions of Knowledge", 1828
----+----+----+----+----+----+----+----+----+----+----+----+
Romain Deltour
> I can see how you could drop either 'entry' or 'entry array', but I can't see how they could be merged. To me they are both fundamental concepts to the way indexes are structured, and I think it would be useful to define them, even if in the final product entry arrays are derived by the system.
Again, I'm still ambivalent about this and in any case I do think that we need a term for what you call an "entry line" (which is AFAIU what is called an "entry" in the current definition).
Michele wrote:
> Perhaps presenting main entries and subentries on the same line this way is possibly what is confusing things? When legacy indexes are converted to epub format, the main entry does not get repeated for every subentry (unless you are suggesting that that should be part of our spec?). In other words, you call "dogs:feeding:36" an entry line, but in an indented layout that would be TWO lines
>> Another possibly significant concept is the last term before a locator. This is
>> part of the definition of 'entry' which we have been considering, but isn't all
>> of it.
>
>
> In XML terms I think you'd call that last entry a "leaf" since the tree structure terminates at that point. But again, functionally speaking, I'm not sure that's important.
* "qualified term": the unambiguous topic/entry term composed of the parent terms and the leaf term.
* "unqualified term / simple term": the term attached to a node in the entry tree, regardless of its ancestor context.
Romain.
Siegman, Tzviya - Hoboken
****************************
Tzviya Siegman * Senior Production Technology Specialist * John Wiley & Sons, Inc.
111 River Street, MS 5-02 * Hoboken, NJ 07030-5774 * 201-748-6884 * tsie...@wiley.com
-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Romain Deltour
Sent: Thursday, May 10, 2012 9:26 AM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
David K. Ream
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of Siegman, Tzviya -
Hoboken
Sent: Thursday, May 10, 2012 4:28 PM
To: epub-work...@googlegroups.com
Glenda Browne
Yes, I used 'entry line' as a temporary shorthand because the word
'entry' was being considered with other definitions. I am happy with the
use of the word 'entry' for this. I also thought 'single entry' might
work as compared with entry array/entry group/entry block.
More inline below...
On 10/05/2012 11:26 PM, Romain Deltour wrote:
...
> Again, I'm still ambivalent about this and in any case I do think that
> we need a term for what you call an "entry line" (which is AFAIU what
> is called an "entry" in the current definition). Michele wrote:
>> Perhaps presenting main entries and subentries on the same line this way is possibly what is confusing things? When legacy indexes are converted to epub format, the main entry does not get repeated for every subentry (unless you are suggesting that that should be part of our spec?). In other words, you call "dogs:feeding:36" an entry line, but in an indented layout that would be TWO lines
> "line" is too close to representational concepts, but as mentioned above, what I think what Glenda calls "entry line" is what is called "entry" in our glossary: it is a node in our tree without its descendants subtree.
>
>
>>> Another possibly significant concept is the last term before a locator. This is
>>> part of the definition of 'entry' which we have been considering, but isn't all
>>> of it.
don't need to define 'main entry' and 'subentry'. Both are terms/topics
at a certain level. We can talk about that level by saying 'level 1' and
'level 2' if we wish, and the system can work out levels when it has to.
>>
>> In XML terms I think you'd call that last entry a "leaf" since the tree structure terminates at that point. But again, functionally speaking, I'm not sure that's important.
Are you saying that 'dogs' and 'grooming' would be unqualified
terms/simple terms, but 'dogs::grooming' and 'dogs::grooming::samoyeds'
would be qualified terms? An 'entry' (entry line or whatever we call it)
could then be defined as a qualified term with composite locator (it
would also have to include an unqualified term that has no children plus
its locator).
Would 'composite term', 'complex term' or 'extended term' be possible
alternative wordings for that concept? In Australia and the UK, a
qualified index entry is the same as what Americans call an index entry
with a gloss.
Cheers,
Glenda.
> It makes me think of a notion of:
> * "qualified term": the unambiguous topic/entry term composed of the parent terms and the leaf term.
> * "unqualified term / simple term": the term attached to a node in the entry tree, regardless of its ancestor context.
>
>
> Romain.
>
>
Broome, Karen
Regards,
Karen Broome
-----Original Message-----
From: epub-work...@googlegroups.com [mailto:epub-work...@googlegroups.com] On Behalf Of Glenda Browne
Sent: Thursday, May 10, 2012 8:42 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Jean Kaplansky
Most people who know markup know parent/child. I'm pretty sure that many people will be very confused by the word "array" in association with indexing.
Just my $.02 USD...
Lee Passey
> atomic entry? entry singularity? discrete entry? - I like these ideas as
> starting points.
split or made any smaller." Likewise, "discrete" means "Separate;
distinct; individual; Non-continuous." Both of the adjectives are useful
in this discussion (as is the concept, if not necessarily the term, of
"entry array.")
An atomic element is one which cannot be further sub-divided, at least
in our specification (we now know that even atoms can be decomposed,
sometimes easily, as with electrons, protons and neutrons, and sometimes
with the help of a Large Hadron Collider -- but we're not in the
business of splitting atoms -- or hairs).
An 'entry' entity is not atomic -- it is defined as a 'term' (a
character string) plus a list of 'locators' or 'locator' substitutes.
A 'term' /is/ atomic -- it is defined as "[a] character string,
representing the indexable item." We do not define what a character
string is, nor do we attempt to break it down into it's component
"sub-atomic particles." When it comes to composition, it is the end of
the line, as far as we go.
A 'locator' is not an atomic entity; it is defined as the composition of
1. An actionable item, 2. a URI, 3. an optional target type, and
possibly 4. text that we include in the locator but which does not
conveniently fit in any of the first three categories (I'm thinking
specifically of the index found at
http://www.supremecourt.gov/opinions/boundvolumes/551bv.pdf).
I suspect that /all/ of the components of a 'locator' are atomic
entities, although given IDPF's "ownership" of the ePubCFI
specification, there may be a valid argument that the "locator URI" is
instead a composite entity (we may want to specify the URI components in
the context of an index).
If you were to gather together a list of 'locators' you would have yet
another compound or composite entity: a 'locator list,' or a 'locator
array,' or a 'locator set,' or a 'locator table,' or a 'locator
collection,' or a 'locator bag.' What it is called is of little
importance so long as everyone understands that what is being referred
to is a list of 'locators.'
I think the same thing could be said of a list of 'entries.' I had
originally thought that an 'entry array' would be equivalent to an
'entry list,' or an 'entry set,' or an 'entry collection.' However, the
definition of 'entry array' on the Wiki does not seem to match that
expectation. As others have pointed out, the definition of 'entry array'
on the Wiki seems substantially equivalent to the definition of a
discrete entry: a 'term,' a list of 'locators,' and a list of
sub-entries (which, I would argue, is simply another kind of locator).
In the instant case, the definition of 'entry array' is virtually
indistinguishable from the definition of 'entry,' and nowhere is there
captured a definition for "a collection of entries."
Returning briefly to the definition of the word "discrete," a discrete
entry is, therefore, a single distinct, individual entity; it may
contain children as a substitute for or in addition to other locators,
but it does not refer in any way to it's siblings -- and the notion of a
"discrete" entity only has meaning where there is also the notion of a
collection of entities.
Now, while all of this discussion may appear to be merely semantic, it
becomes very important when it comes time to translate the specification
into computer code.
Some of you may be familiar with the term ORM -- the Object-Relation
Model. It pretty much doesn't matter which technology is used, this
indexing specification will end up be translated into an Object-Relation
Model; a model where we define objects and their relations to each other.
Atomic elements do not need to be defined by the model; they simply
exist. Composite elements /do/ need to be defined by the model. They are
composed of atomic elements or other composite elements; but eventually
everything needs to be reduced to atoms. And for precision in language,
I think it important that every atom be given a name.
Next, the relationship of specific atomic and composite elements needs
to be defined. The structure of the whole is defined by the elements and
their relationships.
Consider the definition of 'locator.' It is currently defined in a
fairly general fashion. I think every atomic element should be extracted
from that definition, given a name, and then the definition should be
rewritten using the named elements. For example:
A 'term' is an atom comprised either by a character string (not merely
alphanumeric -- all displayable characters are allowed) an image, or both.
A 'URL' is an atom defined by RFC 3305. (Be careful about this
definition -- a URI identifies a resource, but doesn't necessarily tell
you how to locate it; a URL provides a location, but doesn't necessarily
identify the resource at that location. I suspect we are interested in
URLs, not URIs).
An 'actionable item' is a composite entity comprised of the combination
of a 'term' and a 'URL.'
A 'decorator' is an atom distinct from a 'term' comprised either by a
character string, a CSS style declaration, or both, and which serves to
modify a 'locator.' (Technically, the "serves to" clause is not really
important to a programmer, but is useful to those creating the objects).
(Other atoms may be added here).
A 'locator' is a discrete composite entity comprised of an 'actionable
item' and, optionally, a 'decorator' (and any other atoms that we
discover are useful).
A 'locator list' is a discrete composite entity consisting of one or
more discrete locators. In some scenarios, an empty list is useful, but
not so much in this case, so let's stipulate that a 'locator list' must
have at least one discrete 'locator.'
Finally, we come to entries.
An 'entry' is a composite element composed of a 'term' and a 'locator list.'
An 'entry list,' (or 'entry array' if you prefer) is a discrete
composite entity consisting of one or more discrete 'entries.' The
'index body' is an 'entry list.'
From here, the structure could be increasingly complex. For example,
'group' would be defined as a composite element consisting of a discrete
'entry list' and an optional header (which might me an atomic character
string, or which might be an 'actionable item.'
As another example, a sub-entry performs exactly the same function as
the target of a locator; i.e. the entry points to a location, and the
location just happens to be another entry. So let's just allow an 'entry
list' to be a substitute for a 'locator.' Now we can rightly say that a
discrete 'entry' is made up of one 'term' and one 'locator list.' If the
locator list contains an 'entry list' then you have functionally the
same thing as saying you have a permissibly bare term, but with a
subheading. This keeps the model clean, and doesn't require any
exceptions to the "term + locator" rule.
The definitions on the Wiki do not necessarily have to reflect an ORM
orientation. But I think it's important to recognize that whatever
specification is arrived at /must/ be mapped to an Object-Relation Model
before it can be implemented.
David K. Ream
certainly using these words in a strict English sense nor in a IT sense. We
are trying to define terms that relate to indexes within an EPUB. For
instance, I think it has been brought up before that locator as a stand
alone term is ambiguous. Indexers normally mean this to be what you see in
print that directs you to a location. In IT areas, it can, as you say, mean
a URI. We are trying to develop two terms to disambiguate this dichotomy, to
wit something like: locator displayed and locator link.
Also similarly with respect to entry, a dictionary has entries, an index
published in print or electronic form has entries (similar to a dictionary):
the top level headings that are the first things users scan through. But to
indexers, esp. during the index writing/editing phase, work with what they
call an entry that is a set of hierarchical headings (1-n) and either a
locator or a cross reference. So again we are trying to disambiguate the
term entry. Using entry itself to mean the entry in a published index and,
possibly, atomic entry to mean the (heading(s), (locator|xref)) building
block indexes are built from.
Having said that, several different sets of terminology have been proposed
and commented on over recent postings. I'm going to endeavor to
collect/coalesce these for our next working group conf call. I don't believe
any consensus has yet been arrived. The discussion has ranged over a lot of
terminology which may be useful for discussion but not that relates directly
to tags or attributes that would define the structure of an index.
Dave
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of Lee Passey
Sent: Tuesday, May 15, 2012 7:01 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Glenda Browne
As Dave is summarising ideas, I thought I'd just add a couple of brief
comments.
Some use of the word 'entry' (including Lee's discussion below) has
included a locator list. My preferred definition (if we use this sort of
definition of entry) would be to say it only has one locator. An index
is created one locator at a time - this is the logical building block.
To me a chunk like:
dogs::15, 35, 67 is 3 entries.
My other comment would be that to me an 'index body' is made up of a
number of 'index arrays/blocks/lists'.
Cheers,
Glenda.
On 16/05/2012 9:00 AM, Lee Passey wrote:
...bits removed...
> I think the same thing could be said of a list of 'entries.' I had
> originally thought that an 'entry array' would be equivalent to an
> 'entry list,' or an 'entry set,' or an 'entry collection.' However,
> the definition of 'entry array' on the Wiki does not seem to match
> that expectation. As others have pointed out, the definition of 'entry
> array' on the Wiki seems substantially equivalent to the definition of
> a discrete entry: a 'term,' a list of 'locators,' and a list of
> sub-entries (which, I would argue, is simply another kind of locator).
>
> In the instant case, the definition of 'entry array' is virtually
> indistinguishable from the definition of 'entry,' and nowhere is there
> captured a definition for "a collection of entries."
>
>
> An 'entry' is a composite element composed of a 'term' and a 'locator
> list.'
>
> An 'entry list,' (or 'entry array' if you prefer) is a discrete
> composite entity consisting of one or more discrete 'entries.' The
> 'index body' is an 'entry list.'
>
> From here, the structure could be increasingly complex. For example,
> 'group' would be defined as a composite element consisting of a
> discrete 'entry list' and an optional header (which might me an atomic
> character string, or which might be an 'actionable item.'
>
> As another example, a sub-entry performs exactly the same function as
> the target of a locator; i.e. the entry points to a location, and the
> location just happens to be another entry. So let's just allow an
> 'entry list' to be a substitute for a 'locator.' Now we can rightly
> say that a discrete 'entry' is made up of one 'term' and one 'locator
> list.' If the locator list contains an 'entry list' then you have
> functionally the same thing as saying you have a permissibly bare
> term, but with a subheading. This keeps the model clean, and doesn't
> require any exceptions to the "term + locator" rule.
>
> The definitions on the Wiki do not necessarily have to reflect an ORM
> orientation. But I think it's important to recognize that whatever
> specification is arrived at /must/ be mapped to an Object-Relation
> Model before it can be implemented.
>
MicheleR
> Some use of the word 'entry' (including Lee's discussion below) has included a
> locator list. My preferred definition (if we use this sort of definition of
> entry) would be to say it only has one locator. An index is created one locator
> at a time - this is the logical building block. To me a chunk like:
>
> dogs::15, 35, 67 is 3 entries.
This doesn't meant that they can't be three separate records when the index is
/created/, of course. In embedded indexing, each of those three would be a
separate set of tags and the term "dogs" would be repeated; likewise when
working in an indexing tool such as Cindex, these would be three separate
records. But in the final version of the index (which is what we're talking
about here, not how it's created) the term certainly appears only once, and it
seems to make more sense to talk about this as a single entry.
Calling it three entries raises some questions for me:
First: When we get to describing the encoding, would the term then have to be
repeated three times? Or would you allow an "entry" to consist of a locator only?
Second: If the former, e-pubs would need a way to suppress the repeated terms
and display the index in its accustomed form (CSS could do this, probably). If
the latter, then "entry" has become essentially a meaningless word since it
could then be a term alone, a locator alone, a term + cross-reference --
basically anything at all.
Third: I'm not sure I agree that the logical building block is a locator,
because a locator is meaningless without an associated term, right?
Philosophically speaking, if we view it as three entries, seems to me we're
focusing overly much on how the index is /created/, not on how it appears to the
end user. It seems to me that index creation is, and must be, irrelevant to our
standard, right?
All that said, for the reverse index to function, yes, your example would have
to be represented as three separate entries, with the term repeated for each,
placed in the order they appear in the text. But in that case, our definition
of entry would still be "term + locator".
Michele
--
*---*---*---*---*---*---*
Vox audita perit,
littera scripta manet
*---*---*---*---*---*---*
Ushakrishnan
Best Regards
Usha K. | AMNET
Email id: ushakr...@amnet-systems.com
Mobile: +91-944-408-4727
Web: http://www.amnet-systems.com
Disclaimer: This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the sender
and delete this e-mail from your system. If you are not the intended
recipient you are notified that disclosing, copying, distributing or taking
any action in reliance on the contents of this information is strictly
prohibited.
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MicheleR
Sent: Wednesday, May 16, 2012 4:38 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
Lee Passey
> I don't think I can begin to address all the points you raise. But we
> are certainly using these words in a strict English sense nor in a IT
> sense.
Model) has any flavor of IT about it (no IT professional worth his salt
is going to refer to ordered key-value pairs [the definition of an
index] using words like 'entry,' 'term,' 'locator,' or 'decoration').
This isn't about jargon, whether it's indexer jargon or IT jargon, it's
about ontology: what are the component parts of a back-of-the-book
index, how are they related, and how are they used?
It is clear that over time a certain jargon has evolved among
professional indexers, and most have a certain intuitive feel for how
that jargon is used. But intuition is not a substitute for scientific
rigor, and if we have any hope of developing a specification that can be
implemented algorithmically then scientific rigor must be employed.
This is one of the reasons I like inventing a whole new vocabulary for
expressing this ontology: it minimizes the impact on the ontology from
jargon baggage.
Consider the example of the term 'locator.' The definition currently on
the Wiki page is:
> Consists of two parts: (1) actionable character string or image (2)
> URI. It can also have an optional (3) target type, to indicate
> whether a locator points to a figure, a table, a federal statute,
> and so on.
Mr. Ream suggests that when using the term 'locator':
> Indexers normally mean this to be what you see in print that directs
> you to a location.
English use of the word is "a person who locates something"; IT
professionals don't use the word at all, as it is not part of our
jargon), and is only vaguely related to the definition on the Wiki. But
the Wiki definition is of critical importance because it's a good start
towards developing an ontology. If we were to assign the Wiki definition
to the word 'framble', then when someone uses the word 'framble,' you
would know exactly what they meant; by contrast, even now with a clear
definition on the Wiki when someone uses the term 'locator' you cannot
be sure what semantic baggage they are bringing to the conversation.
Another example is the recent exchange between Ms. Rothenberger and Ms.
Browne over the use of the word 'entry.' In my mind, it doesn't matter
what word is used for which concept just so long as 1. the word has only
one meaning, and 2. the meaning is clear.
On the other hand, maybe people aren't ready to start building an
ontology yet, in which case just forget what I said; I'll chime in again
when we get to that point.
David K. Ream
entries".
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of MicheleR
Sent: Wednesday, May 16, 2012 7:08 AM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
David K. Ream
definition.
It has been in use long before there were computers.
I agree we are working towards an ontology.
-----Original Message-----
From: epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] On Behalf Of Lee Passey
Sent: Wednesday, May 16, 2012 12:50 PM
To: epub-work...@googlegroups.com
Subject: Re: [IDX] Defining 'entry' and using the word 'entry' vs 'terms'
> I don't think I can begin to address all the points you raise. But we
Robert Bolick
Jean Kaplansky
mrot...@twcny.rr.com
---- Robert Bolick <robert...@gmail.com> wrote:
> There will
> always be some connotative fuzziness around the words we choose to use.
> Even if we go all "Lewis Carroll" in the effort to set defined terms,
> there will be gray edges to the "slithey tomes".
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master — that's all."
Alice was too much puzzled to say anything; so after a minute Humpty Dumpty began again. "They've a temper, some of them — particularly verbs: they're the proudest — adjectives you can do anything with, but not verbs."
-- Lewis Carroll, Through the Looking Glass
Glenda Browne
You say ' likewise when working in an indexing tool such as Cindex,
these would be three separate records. '. I wonder whether it would
work to call 'dogs:grooming::57' an 'index record'? That would free the
term 'entry' to include multiple locators.
I had assumed that with the encoding each locator would be entered
separately (with all its associated information). But I'm not an expert
on encoding, so happy to go with whatever works. If they are separate I
can envisage things that reading devices could offer - mainly the
reverse index, but also, further down the track, enabling user queries
such as 'show me all the index entries that lead to images'. This would
involve separating locators with specific decorations attached and just
presenting them.
Cheers,
Glenda
mrot...@twcny.rr.com
>
> I had assumed that with the encoding each locator would be entered
> separately (with all its associated information).
>
Part of our job is to recommend how indexes should be encoded in epubs. Since we haven't gotten to the question of encoding yet, we haven't tackled this question.
I know we're trying to settle terminology first, but how we define these words or phrases is at least loosely coupled to how we will encode the atomic components, so let's talk about it for a minute.
I'm not sure that we can or should require this encoding approach, for several reasons. First, that might impose a burden on publishers who are doing anything other than embedded indexing, particularly paper-to-epub but also on electronic publishers whose publishing process may not accommodate outputting an index in that form. Second, it would absolutely require a CSS style sheet that suppresses the repeated terms, either publisher-provided or built into the e-reader. Do we want to put that requirement on them? Third, think of what indexers most often deliver: an RTF file or a Word file. Does that easily support encoding each locator separately with all its ancestor terms? Will publishers have to write scripts to tweak them? Or will publishers begin to demand that indexers provide a fully-encoded index instead? Do the tools support that?
Please note, I am NOT arguing that the standard we come up with should require NO technical adaptations on the part of publishers or indexers. But the barriers are already pretty low, and yet still indexers are being left out of epubs or implemented in a sub-par manner. Any new requirement we put in place should be weighed against the impact it will have on adoption. If the answer turns out to be yes, we think that every locator should be encoded separately with its associate ancestor term(s), I'm fine with it, I just want to make sure we understand all the ramifications of that decision.
> If they are separate I
> can envisage things that reading devices could offer - mainly the
> reverse index, but also, further down the track, enabling user queries
> such as 'show me all the index entries that lead to images'. This would
> involve separating locators with specific decorations attached and just
> presenting them.
A second point, perhaps just semantic, is that "show me all the index entries that lead to images" would not be done by looking at the decorations, because the decorations might not exist in the file at all but rather be generated and displayed by the CSS. It would be done by looking at an attribute of the locator e.g. "target-type". So for example target-type="figure" or target-type="statute" or target-type="abstract" or whatever. (That's pseudo-code, of course, just to give you the idea).
Michele
Glenda Browne
Yes, I think you hit the nail on the head. I assumed that each locator
would be entered separately, and also thought that this would be
necessary if we are to describe semantics rather than presentation.
The current definition for 'entry' on the wiki says 'For legacy data one
entry could contain multiple locators.'. I can see that this would be a
useful option for publishers who don't want to go to the trouble of more
detailed structuring, but I thought it suggested that one locator per
entry would also be an option.
From the point of view of index output, my guess is that this will not
be a huge problem for indexers using professional software. The indexes
are already stored in a database structure. In SKY Index you can set
coding to go before and after terms in the index (perhaps not before and
after locators) and you can set coding to go at the beginning of the
whole index. For other people creating indexes it may be more difficult
to create complex outputs, and I don't know how CINDEX and Macrex would
work. Most indexes would have some style formatting and I had hoped it
would not be that difficult to convert the word processor or other
output to the required EPUB style.
Cheers,
Glenda.