[Linkbat-devel] Content KU Sub-Types

[James Mohr <linkbat-admin@ji...>]

Hi All!

I have been thinking that it might be useful to have sub-types for the Content 
KUs. For example, you could have: fact, misconception, problem. A fact, is 
the standard Content KU and simply makes a statement. A misconception is also 
a statement of fact (for the most part) but the goal is to dispell a common 
misconception or misunderstanding. A problem is something can cause 
"problems". I am having trouble thinking of examples of "problems", but I 
think somewhere along the line it might be useful. 

Comments?

Regards,

Jim
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

Re: [Linkbat-devel] Linkbat Data Model

[Shanta McBain <shanta@fo...>]

No Not had time to work on this project. Disk quota exceeded problem
deleted a few unused directories. Works now.


On Sat, 2002-11-30 at 08:43, James Mohr wrote:
> Hi All!
> 
> Please review and email your comments this weekend. I would really like to 
> finalize the model and start working on the code. 
> 
> Shanta, have you made any changes to eXtropia pages since last weekend? I just  
> tried the link you privided and it eventually times out:
> 
> http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat
> 
> Regards,
> 
> Jim
-- 
Yours Truly

Shanta McBain
HTTP://computersystemconsulting.ca

[Linkbat-devel] Linkbat Data Model

[James Mohr <linkbat-admin@ji...>]

Hi All!

Please review and email your comments this weekend. I would really like to 
finalize the model and start working on the code. 

Shanta, have you made any changes to eXtropia pages since last weekend? I just  
tried the link you privided and it eventually times out:

http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat

Regards,

Jim

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

Re: [Linkbat-devel] DB or not DB, that is the question

[James Mohr <linkbat-admin@ji...>]

On Wednesday 27 November 2002 20:24, Hal F. Gottfried wrote:
> How about storing the DATA in teXtML it's a native XML database

From what I was able to find it looks propriatary/commercial and Windows-only. 

regards,

jim

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

RE: [Linkbat-devel] DB or not DB, that is the question

[Hal F. Gottfried <hgottfried@pr...>]

How about storing the DATA in teXtML it's a native XML database

-----Original Message-----
From: linkbat-devel-admin@...
[mailto:linkbat-devel-admin@...] On Behalf Of James
Mohr
Sent: Wednesday, November 27, 2002 3:30 PM
To: linkbat-devel@...
Subject: [Linkbat-devel] DB or not DB, that is the question


Hi All!

Well, I have been thinking about this and think that we will still need
to 
store the data is some way for dynamic access. One place is for the
questions 
and answers. We could *theoretically* create these pages in advance, but

would still need a method to access them randomly, plus be able to
select 
questions based on the current topic. So I see very little difference in

reading a DB to create the questions dynamically as compared to creating
some 
"artificial" database to store the pre-made pages so that we can access
them 
randomly. 


Also, an eventual goal is to have a search mechanism that not only goes 
through the tutorial pages, but also through the KUs. So I think that a 
storage and index mechanisms is unavoidable, so I think that we need to
go 
forward with the idea the KUs will be imported into a database.

However, I still think that a lot of the pages **could** be created on
the 
fly, such as the glossary terms and MoreInfo. Anyone got any comments
about 
all this?

Regards,

jim

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what
others think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Linkbat-devel mailing list
Linkbat-devel@...
https://lists.sourceforge.net/lists/listinfo/linkbat-devel

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
 

[Linkbat-devel] DB or not DB, that is the question

[James Mohr <linkbat-admin@ji...>]

Hi All!

Well, I have been thinking about this and think that we will still need to 
store the data is some way for dynamic access. One place is for the questions 
and answers. We could *theoretically* create these pages in advance, but 
would still need a method to access them randomly, plus be able to select 
questions based on the current topic. So I see very little difference in 
reading a DB to create the questions dynamically as compared to creating some 
"artificial" database to store the pre-made pages so that we can access them 
randomly. 

Also, an eventual goal is to have a search mechanism that not only goes 
through the tutorial pages, but also through the KUs. So I think that a 
storage and index mechanisms is unavoidable, so I think that we need to go 
forward with the idea the KUs will be imported into a database.

However, I still think that a lot of the pages **could** be created on the 
fly, such as the glossary terms and MoreInfo. Anyone got any comments about 
all this?

Regards,

jim

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

RE: [Linkbat-devel] Linkbat Dataflow

[Hal F. Gottfried <hgottfried@pr...>]

Nope James, sounds good to me, I think you covered everything. I'm also
reviewing all of the
other mails that where sent to see if there is anything that needs my
attention. BTW: I am Hal, an
XML instructor with a IT training company. 

-----Original Message-----
From: linkbat-devel-admin@...
[mailto:linkbat-devel-admin@...] On Behalf Of James
Mohr
Sent: Tuesday, November 26, 2002 5:20 PM
To: linkbat-devel@...
Subject: Re: [Linkbat-devel] Linkbat Dataflow


Hi All!

Sorry, I'm doing it again. I forget to keep a discussion with Hal
Gottfried on 
the list. Hal and I have been discussing the XML implementation in the
data 
files and he has said he can write the DTD when we get the model
finalized. 

So, to sum up our discussions, we both seem to agree that accessing the
data 
will be speeded up by a conversion to either CSV or a database. Hal made
a 
couple of comments that me think that we could actually create a lot of
the 
pages in advanced and not at run-time, thus speeding up things even more
so. 
Since the data is static, once copied to the server, there is no reason
to 
parse most of it on the fly.  For example:

- Content pages. They are parsed at runtime to create the links and
popups for 
the glossary, links to other tutorial pages, etc. 
- Glossary pages. Created completely at run time and include links to
other 
glossary terms and pages that references this glossary term. 
- MoreInfo pages. Created completely at run time and include links to
other 
sites. 

I see no reason why these cannot be created in advance. We would just
need to 
make sure that whatever display mechanism we use knows how to load the 
correct page. To me that's a heck of a lot easier than creating the
pages on 
the fly. 

This brings up a **huge** question, which is particularly of interest to

Shanta. If we create all of the pages in advance, there does to seem to
be a 
need a pressing need for an SQL Database. The reason for it was the 
efficiency during data access. So, the question is whether we gain
anything 
by creating one. In my mind, it doesn't matter if the pre-processing
takes 
longer as it would with an SQL DB.

How do the rest of you see this?

Hal suggested including the PageID as an attriube to the <Type> tag and
we 
were both thinking that we could the sub-type as an attribute of the
<Type> 
tag.

<Type id="45">Page</Type>
<Type url="http://www.linux.org">MoreInfo</Type>;
<Type subtype="verb">Glossary</Type>

This makes sense as the sub-type is a characteristic of the type and not
the 
actual KU.

For the questions, we have the issue of an empty <Reason> tag as a
reminder to 
add something. It might be simpler to have the text of the Reason an 
attribute of the tag, like this:

<reason answer="why this is correct" />

If it's empty we don't carry arounf the extra baggage.

Did I forget anything important, Hal?

Regards,

jimmo

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what
others think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Linkbat-devel mailing list
Linkbat-devel@...
https://lists.sourceforge.net/lists/listinfo/linkbat-devel

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
 

Re: [Linkbat-devel] Linkbat Dataflow

[James Mohr <linkbat-admin@ji...>]

Hi All!

Sorry, I'm doing it again. I forget to keep a discussion with Hal Gottfried on 
the list. Hal and I have been discussing the XML implementation in the data 
files and he has said he can write the DTD when we get the model finalized. 

So, to sum up our discussions, we both seem to agree that accessing the data 
will be speeded up by a conversion to either CSV or a database. Hal made a 
couple of comments that me think that we could actually create a lot of the 
pages in advanced and not at run-time, thus speeding up things even more so. 
Since the data is static, once copied to the server, there is no reason to 
parse most of it on the fly.  For example:

- Content pages. They are parsed at runtime to create the links and popups for 
the glossary, links to other tutorial pages, etc. 
- Glossary pages. Created completely at run time and include links to other 
glossary terms and pages that references this glossary term. 
- MoreInfo pages. Created completely at run time and include links to other 
sites. 

I see no reason why these cannot be created in advance. We would just need to 
make sure that whatever display mechanism we use knows how to load the 
correct page. To me that's a heck of a lot easier than creating the pages on 
the fly. 

This brings up a **huge** question, which is particularly of interest to 
Shanta. If we create all of the pages in advance, there does to seem to be a 
need a pressing need for an SQL Database. The reason for it was the 
efficiency during data access. So, the question is whether we gain anything 
by creating one. In my mind, it doesn't matter if the pre-processing takes 
longer as it would with an SQL DB.

How do the rest of you see this?

Hal suggested including the PageID as an attriube to the <Type> tag and we 
were both thinking that we could the sub-type as an attribute of the <Type> 
tag.

<Type id="45">Page</Type>
<Type url="http://www.linux.org">MoreInfo</Type>;
<Type subtype="verb">Glossary</Type>

This makes sense as the sub-type is a characteristic of the type and not the 
actual KU.

For the questions, we have the issue of an empty <Reason> tag as a reminder to 
add something. It might be simpler to have the text of the Reason an 
attribute of the tag, like this:

<reason answer="why this is correct" />

If it's empty we don't carry arounf the extra baggage.

Did I forget anything important, Hal?

Regards,

jimmo

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

RE: [Linkbat-devel] Linkbat Dataflow

[Hal F. Gottfried <hgottfried@pr...>]

I have been on the road, I'll read through all the emails this week.
What are my tasks?


-----Original Message-----
From: linkbat-devel-admin@...
[mailto:linkbat-devel-admin@...] On Behalf Of James
Mohr
Sent: Sunday, November 24, 2002 12:02 PM
To: linkbat-devel@...
Subject: [Linkbat-devel] Linkbat Dataflow


Hi All!

I have included a diagram of how I envision the dataflow within linkbat.
It is 
also available online (linkbat.sourceforge.net/dataflow.html). 

At the bottom we have the data management layer, which, as it's name
implies, 
is where the management of the data occurs. That is new data, new KUs,
new KU 
types, changes etc are inserted into the system at this level. Above
that is 
the data access layer, which provides the data to the presentation
layer. 

Between the data management and data access layers are the perl routines
that 
read the XML files and convert the data into the appropriate files. Note
that 
there are two lines from the XML files into the data access layer, one
into 
CSV and one into SQL. My ultimate goal is to give the user a choice as
to 
which format the data should be used. 

My perception is that it will be unavoidable to store the data in
intermediate 
files during the conversion, or at the very least the data will be in a
form 
in memory that allows for easy conversion to CSV. That is, the KUs and 
reference indexes will probably be stored in an array and it would be a 
simple matter of looping through the arrays and then writing out the
data to 
text files. However, instead of writing the data to text files, it could

simply be inserted into the database tables. Therefore, I could imagine
a 
command line options that determines where the data is writen CSV file
or DB. 

One important aspect of the code is adding data to the system. Once it
is in 
the database, then adding new KUs becomes becomes a key issue. Each KU
will 
need to have a unique ID, which I think should be added during the
conversion 
to CSV/DB and not stored within the XML file. This will be used for the 
references between KUs. A see a problem there when we add data to the
system 
since the new data will not have any knowledge of the KU IDs. 

I see one solution as a table that contrains the relationship between KU
text 
and KU ID, which probably should also contain the KU type. So each row
looks 
like this:

KUID:KU_TEXT_FROM_XML_FILE:KU_TYPE

When a new KU is added we can reference existing KUs using this table. 
However, how do we add the references from existing KUs to the new ones.
We 
cannot simply add them to the existing database as the will not be in
the 
original XML files. Therefore, I see the only way to add KUs is to redo
the 
**complete** data import each time we add a new a KU.

Comments? Ideas?

In the transition from data access to presentation I see an "issue" with
the 
different data sources. I would like to see the code that the
presentation 
layer uses to be **independant** of the data source. That is, the
presenation 
layer makes a request of the data access layer to deliver a specific
piece or 
set of data and the data access layer takes care of the rest. For
example, 
the presentation layer would call functions similar to this:

get_single_content_ku(KU_UD)
get_all_moreinfo_ku(TOPIC)
get_all_related_moreinfo_ku(KU_ID)

In each case the presentation layer wants a piece or set of data and
asks the 
data access layer to deliver it. It is then the responsibility of the
data 
access layer to determine if the data source and the proper method to
access 
that data source in order to deliver the requested data. By
standardizing the 
interface, I see it a lot easier to have different delivery methods.
Each can 
load the necessary perl modules (for example) and simple call the
appropriate 
functions. How the delivery process interacts with the web server is 
dependant on the delivery and web server.

Comments? Ideas?

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what
others think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
 
  

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002
 
  

[Linkbat-devel] Linkbat Dataflow

[James Mohr <linkbat-admin@ji...>]

Hi All!

I have included a diagram of how I envision the dataflow within linkbat. It is 
also available online (linkbat.sourceforge.net/dataflow.html). 

At the bottom we have the data management layer, which, as it's name implies, 
is where the management of the data occurs. That is new data, new KUs, new KU 
types, changes etc are inserted into the system at this level. Above that is 
the data access layer, which provides the data to the presentation layer. 

Between the data management and data access layers are the perl routines that 
read the XML files and convert the data into the appropriate files. Note that 
there are two lines from the XML files into the data access layer, one into 
CSV and one into SQL. My ultimate goal is to give the user a choice as to 
which format the data should be used. 

My perception is that it will be unavoidable to store the data in intermediate 
files during the conversion, or at the very least the data will be in a form 
in memory that allows for easy conversion to CSV. That is, the KUs and 
reference indexes will probably be stored in an array and it would be a 
simple matter of looping through the arrays and then writing out the data to 
text files. However, instead of writing the data to text files, it could 
simply be inserted into the database tables. Therefore, I could imagine a 
command line options that determines where the data is writen CSV file or DB. 

One important aspect of the code is adding data to the system. Once it is in 
the database, then adding new KUs becomes becomes a key issue. Each KU will 
need to have a unique ID, which I think should be added during the conversion 
to CSV/DB and not stored within the XML file. This will be used for the 
references between KUs. A see a problem there when we add data to the system 
since the new data will not have any knowledge of the KU IDs. 

I see one solution as a table that contrains the relationship between KU text 
and KU ID, which probably should also contain the KU type. So each row looks 
like this:

KUID:KU_TEXT_FROM_XML_FILE:KU_TYPE

When a new KU is added we can reference existing KUs using this table. 
However, how do we add the references from existing KUs to the new ones. We 
cannot simply add them to the existing database as the will not be in the 
original XML files. Therefore, I see the only way to add KUs is to redo the 
**complete** data import each time we add a new a KU.

Comments? Ideas?

In the transition from data access to presentation I see an "issue" with the 
different data sources. I would like to see the code that the presentation 
layer uses to be **independant** of the data source. That is, the presenation 
layer makes a request of the data access layer to deliver a specific piece or 
set of data and the data access layer takes care of the rest. For example, 
the presentation layer would call functions similar to this:

get_single_content_ku(KU_UD)
get_all_moreinfo_ku(TOPIC)
get_all_related_moreinfo_ku(KU_ID)

In each case the presentation layer wants a piece or set of data and asks the 
data access layer to deliver it. It is then the responsibility of the data 
access layer to determine if the data source and the proper method to access 
that data source in order to deliver the requested data. By standardizing the 
interface, I see it a lot easier to have different delivery methods. Each can 
load the necessary perl modules (for example) and simple call the appropriate 
functions. How the delivery process interacts with the web server is 
dependant on the delivery and web server.

Comments? Ideas?

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] XML Validation

[James Mohr <linkbat-admin@ji...>]

HI All!

Luu is now done with the CSV->XML conversion code and he can now start working 
on the validation code. 

I see the validation as a two step processs, both in terms of coding and the 
actual work. The first thing is to make sure we have a valid XML file, based 
on the not-yet-defined DTD. Even without the DTD, the principles are clear (I 
hope). 

A validation/check programm would look to make sure that all tags that are 
supposed to have a match have one, all tags that are supposed to be there are 
there and so on. For example, we decided that each answer should have the 
Reason tag pair, even if was empty. If not, the validation program will 
report it. Specific tags can only have certain attributes, like the Command 
type cannot have url="" attribute.

The second step, which I see for sometime in the future is a validation of the 
data. For example, a future version could check to make sure that references 
are made only to KUs that are defined elsewhere. That would require reading 
in all of the KUs first, and would basically be the same code as the parse 
without the ouput.  

However, the parsing code will need to know about all KUs before it begins to 
write the indexes/cross-references. If there is a reference to a KU that does 
not exist, what should it do, report it and move on. We **could** have an 
option that simply runs through the process without writing it, as well as an 
option to check first and then write if things are okay. Comments?

What concerns me is that a validation will require a full parse of the file, 
similar to the parse/export routines (to CSV or DB). The question is how much 
of the code will be the same? I would hate Luu to work on code that is 
duplicated in the parse and export routines. 

Luu, one thing you might want to check is to see if there are any perl modules 
for XML validation on http://www.cpan.org. I found a number of XML modules when I 
looked a couple of weeks, ago, but I cannot remember if there was anything 
about validation.

Rama, are you there? Have you had done anything yet. I realize that you don't 
have the finished XML files (I'll get them done this weekend thanks to Luu's 
code). I'm just curious what you have done. Maybe we can combine the work in 
order to reduce the amount code and the time. 

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] Re: [Linkbat-writers] Email addresses

[<scorcora@wi...>]

This one is good. :)

staci

-----------------------------------
Truth is like the sun: Sometimes it's hidden, and sometimes you wonder
if it's really there at all, but if you don't believe, it goes right
on as it always has.

On Thu, 21 Nov 2002, James Mohr wrote:

> HI All!
>
> For many of you I have your SourceForge addess for the mailing list.
> (user_name@...) For others I have non-sourceforge addresses.
> Personally, I think the non-sourceforge address is better so that it does not
> have to get redirected. But, since the mailing list and the email addresses
> are all handled by SF, it shouldn't really matter. In any event, let me know
> which address you prefer for the mailing list and will make the necessary
> changes.
>
> Regards,
>
> jimmo
>
> --
> ---------------------------------------
> "Be more concerned with your character than with your reputation. Your
> character is what you really are while your reputation is merely what others
> think you are." -- John Wooden
> ---------------------------------------
> Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linkbat-writers mailing list
> Linkbat-writers@...
> https://lists.sourceforge.net/lists/listinfo/linkbat-writers
>

Re: [Linkbat-devel] Re: question on moreinfo.data (Everyone please read)

[James Mohr <linkbat-admin@ji...>]

On Wednesday 20 November 2002 21:18, Shanta McBain wrote:
> This file is all ready converted to MySQL.
> Add what ever field you like.
> to see go to my devel site
>
> http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat
> Create an account and log in to see the link to the table.

Sorry, but I am missing the point of the question manager? I see a number of 
headings with no content. "View All Records" also show me nothing.  Is this 
intended as the interface to add questions to the system? Unless this 
mechanism can insert the question into a KU in the XML file and make the 
necessary references I am missing the point. 

Just to give it a go, I tried to add a question and got this: 

Error Notice 

I am sorry, but there were some errors in your submission. Please correct the 
errors to continue... 
doUpdate failed: Changes CANNOT BE rolled back 0 completed actions removed 
from update queue Could not add record; DBI error: Duplicate entry '127' for 
key 1 at ../Modules/Extropia/Core/DataSource/DBI.pm line 143. 


Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

Re: [Linkbat-devel] Re: question on moreinfo.data (Everyone please read)

[James Mohr <linkbat-admin@ji...>]

On Wednesday 20 November 2002 21:05, Luan Luu wrote:
> Hi All,
>
> The seperator ":" is good for now in my opinion, since the other
> characters, we will also have in some of the other data files.

True.

> The reason tag should be there and stay empty, not removed, because when
> you extract XML to DB, i guess we expect a REASON tag to be there.

OK. Fine with me. However, I just want to make sure that we have consistant 
rules. That is, we say that even if the tag is empty it **must** be present  
in all cases. If it's okay to leave it out sometimes and not others, people 
will forget and it gets confusing as to when and where it is allowed.

> Is it possible the tyk.data file be modified a little bit?  Like you
> mentioned, there are a couple of character in there which can not be
> convert into valid XML format, such as the alone '&' need to change to
> '&', in the line number 45.  The othere '&' in the data file was
> already in converted format, so it is alright. only the previous one
> mentioned causes problem. Also, I tried to convert all the < and > into the
> '&lt;' and '&gt;' respectively.  Is that ok?

I don't think that will be a problem (I hope). The fact that we need to use 
special characters like this in the text is unavoidable as it's simply part 
of Linux. 

> You mentioned the Topics and TopicRef tag should be insert into all the
> data file?  Where do you think it should be?
>
> For the new dyk.data.NEW you sent me, it would produce this.
>
> <KnowledgeUnit>
>    <Attributes>
>       <Type>Concept</Type>
>       <Text>Linux can be started from any partition.</Text>
>    </Attributes>
>    <Pages>
>       <PageRef primary="true">106</PageRef>
>    </Pages>
>    <Questions>
>
>    </Questions>
> </KnowledgeUnit>
>
> Where should the topics and topicref goes?

Good question.  My feeling is that the Questions should come last. However, 
the order of the KU references is unimportant, right? That is, the pages 
could come first and then the Topics or the Topics first and then the pages. 
However, (again my feeling) the topics are important enough and will "always" 
be there, so they should come after the attributes. You then end up with 
this:

<KnowledgeUnit>
   <Attributes>
      <Type>Concept</Type>
      <Text>Linux can be started from any partition.</Text>
   </Attributes>
   <Topics>
      <TopicRef> topic1</TopicRef>
      <TopicRef> topic2</TopicRef>
   </Topics>
   <Pages>
      <PageRef primary="true">106</PageRef>
   </Pages>
   <Questions>

   </Questions>
</KnowledgeUnit>

regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] Netiquette

[James Mohr <linkbat-admin@ji...>]

Hi All!

In principle it is considered bad "netiquette" to snip out portions of email, 
news posts, etc. without marking your reply (i.e. <snip>). However, I am not 
too picky and I think that in this closed group we can all accept that 
portions will be removed to save space and time.

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] Re: [Linkbat-writers] Linkbat Knowledge Unit Topics

[James Mohr <linkbat-admin@ji...>]

On Thursday 21 November 2002 07:37, Navin Dhanuka wrote:
> Under OS we should also cover Kernel Internals

I do a fair bit of that already. However, there is a lot more that I want to 
include.

> Linux-Windows Integration could be names as
> GNU/Linux & MS Windows

You're on the right track with that, but I think it is too long. Shar Houlihan 
suggested "Linux & Windows". That's short and sweet.

> .. Switching your OS to Linux
> .... Xwindow System (Gnome, KDE)
> .... Browsers, Email-Clients (Opera, Netscape, Konqueror)
> .... Word Processors & Spread Sheets (OpenOffice.org)
> .... Games (Doom)

These are on my "wish list" of topics to cover. Also, a number of these topics 
will automatically fall into the topics GUI, Applications and so forth, so we 
need to be careful not to repeat too much. Personally, I bite my tongue when 
talking about games. Although I do play occassional, computers are a tool. 
However, we (that I) need to keep in mind that many people see that the 
"work" they do with computers is secondary and playing games is primary. ;-)

> .. Migrating your Network to Linux
> ....  Linux on Server & Win on Clients
> ....  Linux Everywhere

I think this is the big "Integration" topic. Its more than just "migration" as 
we need to addess issue where you **cannot** move to Linux such as 
applications that do not exist on Windows or others on the network that do 
not want to move. I have a small section on Samba (in the networking chapter) 
that I want to expand. However, I am still undecided as to whether to move it 
into the Linux-Windows chapter. Comments?

> .. File Systems
> .... (ext2, xt3, reiserfs, xfs) vs (fat, fat32, ntfs)

Same thing as apps. I discuss the filesystem in details under the Linux 
chapters and don't want to repeat it here (however, I only discuss ext2 but I 
want to cover the others). However, a comparision of the various filesystems 
along with Windows is a good idea.

> Pogramming
> ..Shell Scriting
> ..C
> ..Sed/AWK

I'm missing what you are getting at. Are you suggesting a whole new chapter on 
Programming? I like that. sed, perl and awk are under "editing files" which 
has bothered me from the beginning. Maybe "editing" should be expanded to 
include emacs and maybe so other non-GUI editors. Or maybe also the GUI 
editors. Hmmmm. Comments?

> >This is not the same as "Users" which refers to topics related to user
> >accounts (passwords, permissions, allowing remote access, etc.)
>
> This will go under Administration topic

Exactly.

>
> >Please let me hear from you as soon as possible. (Please, be sure to send
> >to
> >the list and not just to me!)

I keep forgetting that, don't I? ;-)

Regards,

jimmo

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] I'm lazy

[James Mohr <linkbat-admin@ji...>]

Hi All!

I know this will sound stupid. But I want to make sure that we all understand 
what I am talking about.  When I say SF, I am referering to SourceForge. So, 
when I say the "task list on SF",  then people know that this is the "task 
list on SourceForge". By the way, do people know about all the wonderful 
things that SF let's us keep track of like to-do tasks, bugs, feature 
requests, etc. I have added a lot of tasks already, although most apply to 
just the content writers and editors. Also many of the code tasks might 
become unnessary.  

If you are not familiar with it log into SF and take a look. Everyone is 
listed as a "technician" which will allow you to see the items and assign 
them to yourselves. (If you want).

Regards,

jimmo
-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] Email addresses

[James Mohr <linkbat-admin@ji...>]

HI All!

For many of you I have your SourceForge addess for the mailing list.  
(user_name@...) For others I have non-sourceforge addresses. 
Personally, I think the non-sourceforge address is better so that it does not 
have to get redirected. But, since the mailing list and the email addresses 
are all handled by SF, it shouldn't really matter. In any event, let me know 
which address you prefer for the mailing list and will make the necessary 
changes.

Regards,

jimmo

-- 
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info

[Linkbat-devel] Re: [Linkbat-writers] Linkbat Knowledge Unit Topics

[Navin Dhanuka <navindhanuka@ms...>]

Hello,

Under OS we should also cover Kernel Internals

Linux-Windows Integration could be names as
GNU/Linux & MS Windows
.. Switching your OS to Linux
.... Xwindow System (Gnome, KDE)
.... Browsers, Email-Clients (Opera, Netscape, Konqueror)
.... Word Processors & Spread Sheets (OpenOffice.org)
.... Games (Doom)

.. Migrating your Network to Linux
....  Linux on Server & Win on Clients
....  Linux Everywhere

.. File Systems
.... (ext2, xt3, reiserfs, xfs) vs (fat, fat32, ntfs)

Pogramming
..Shell Scriting
..C
..Sed/AWK


>This is not the same as "Users" which refers to topics related to user
>accounts (passwords, permissions, allowing remote access, etc.)
This will go under Administration topic

>Please let me hear from you as soon as possible. (Please, be sure to send 
>to
>the list and not just to me!)

College lab will be off for 4-5 days, I will mail my complete list of topics 
, subtopics after that.

Thanks..!!


Navin Dhanuka

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Linkbat-devel] Re: question on moreinfo.data (Everyone please read)

[Shanta McBain <shanta@fo...>]

Ps I have already added a Category field in anticipation of Jim's idea
of giving the user more questions in a category if they make errors. 

On Wed, 2002-11-20 at 12:18, Shanta McBain wrote:
> On Wed, 2002-11-20 at 12:05, Luan Luu wrote:
> > Hi All,
> > 
> > The seperator ":" is good for now in my opinion, since the other characters, 
> > we will also have in some of the other data files.
> > 
> 
> > The reason tag should be there and stay empty, not removed, because when you 
> > extract XML to DB, i guess we expect a REASON tag to be there.
> > 
> > Is it possible the tyk.data file be modified a little bit?  Like you 
> > mentioned, there are a couple of character in there which can not be convert 
> > into valid XML format, such as the alone '&' need to change to '&', in 
> > the line number 45.  The othere '&' in the data file was already in 
> > converted format, so it is alright. only the previous one mentioned causes 
> > problem. Also, I tried to convert all the < and > into the '&lt;' and '&gt;' 
> > respectively.  Is that ok?
> > 
> 
> This file is all ready converted to MySQL.
> Add what ever field you like.
> to see go to my devel site
> 
> http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat
> Create an account and log in to see the link to the table.
> 
> 
> > You mentioned the Topics and TopicRef tag should be insert into all the data 
> > file?  Where do you think it should be?
> > 
> > For the new dyk.data.NEW you sent me, it would produce this.
> > 
> > <KnowledgeUnit>
> >    <Attributes>
> >       <Type>Concept</Type>
> >       <Text>Linux can be started from any partition.</Text>
> >    </Attributes>
> >    <Pages>
> >       <PageRef primary="true">106</PageRef>
> >    </Pages>
> >    <Questions>
> > 
> >    </Questions>
> > </KnowledgeUnit>
> > 
> > Where should the topics and topicref goes?
> > 
> > thanks.
> > 
> > Best Regards
> > -Luu
> > 
> > 
> > 
> > 
> > 
> > >From: James Mohr <linkbat-admin@...>
> > >Reply-To: linkbat-admin@...
> > >To: linkbat-devel@...
> > >Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please 
> > >read)
> > >Date: Tue, 19 Nov 2002 11:03:51 +0100
> > >
> > >(Note this was sent to the list.)
> > >
> > >Hey everyone, the conversion is almost done (well, at least the code for 
> > >it).
> > >Thanks Luu! However, there are some important questions to answer NOW, 
> > >before
> > >we continue. PLEASE, please, please read this and give me your input.
> > >
> > >On Tuesday 19 November 2002 00:31, Luan Luu wrote:
> > > > according the the moreinfo.data, the format:
> > > > ID#:TYPE:DESCRIPTION:LOCATION
> > > >
> > > > the XML are
> > > >
> > > > <KnowledgeUnit>
> > > > <Atrributes>
> > > >   <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type>
> > > >   <Text>[DESCRIPTION]</Text>
> > > > </Atrributes>
> > > > </KnowledgeUnit>
> > > >
> > > > In the reference to the brackets, is the pointer the the type, location,
> > > > and description like that?
> > >
> > >Perfect. The only question is whether we should actually do it that way or
> > >not. That is, should the sub-type and location be attributes within the
> > ><Type> tag or should they be seperate tags, i.e. <SubType>  <Location>?
> > >
> > >By gut feeling is that they should be attributes within the  <Type> tag. 
> > >They
> > >not necessarily attributes of KU, but rather provide additional info for 
> > >the
> > >type.
> > >
> > >Comments anyone? This needs to be answered before we continue.
> > >
> > > > is the url be absolute path with the http infront right?
> > >
> > >Yes. You will note that in the data file, they just begin with // and not
> > >http://. This was because I made an unwise decision to use the colon (:) as
> > >the field seperator. However, the colon appears frequently in Linux
> > >(especially with URLs) so it became a problem.
> > >
> > >I was going to change to something like a pipe (|) which comes less
> > >frequently. Regardless, we will have a problem since the odds are that
> > >whatever character we use, it will appear in text somewhere in the data.
> > >
> > >Obviously this is not a problem when we import directly into a database.
> > >However, as I said to Shanta, I don't have a problem with importing the 
> > >files
> > >directly into a database for the first release. However, eventually I want
> > >the system to be independant of the data source (CSV, database)  and
> > >independant of the presentation (eXtropia, other portal).  Therefore, we 
> > >need
> > >to consider a new seperator.
> > >
> > >Suggestions?
> > >
> > > > Inside the tyk xml question tags, there is a topicRef tag, which is the
> > > > reference of the PAGE_ID.  So, do you want to put the Page_id in the
> > > > topicRef tags or the actual topic name in the page.data ?
> > >
> > >The TopicRef is a references to a topic, such as Administration, 
> > >Networking,
> > >Security, etc. This is just text. There are PageRef tags and these contains
> > >the page *name* from page.data. However, I am nop longer sure we should do 
> > >it
> > >that way (see below). This needs to be changed in tykToXML.pl.
> > >
> > >Keep in mind that the questions will exist only within a KU. This KU will 
> > >have
> > >a primary page so we automatically have the primary page for the question.
> > >However, the question could reference multiple topics.
> > >
> > >We have a problem with some of the questions where an angle bracket is one 
> > >of
> > >the answer ("What symbol is used to "pipe" two commands together?") This
> > >means we have two angle brackets together (<< or >>) which could confuse 
> > >the
> > >XML parser. There are only a few and we can change them by hand. We just 
> > >need
> > >to be aware of them.
> > >
> > >Also watch the format of the answers, even for the T/F questions:
> > >
> > >         <Correct>
> > >                 <Text>T</Text>
> > >                 <Reason>why this answer is correct</Reason>
> > >         </Correct>
> > >
> > >not just
> > >
> > ><Correct>T</Correct>
> > >
> > >I think that as much as possible it is better to have the same format for 
> > >all
> > >types of questions.  More than likely, "fill in the blank" type questions
> > >won't have an <Incorrect> answer, but I still want to have a <Reason> tag 
> > >to
> > >provide an explanation why the answer is correct.
> > >
> > >However, since we do not yet have the reasons, I think you should simply 
> > >leave
> > >as <Reason></Reason>. I think if we leave the text as "put your reason why 
> > >is
> > >correct/incorrect. " we might forget to change it and then displaying that
> > >text would look silly. If the <Reason> tag is empty, we can just ignore it.
> > >OR we could simply not include the <Reason> tag at this point. What do you
> > >think?
> > >
> > >With the Glossary KUs please create a <GlossaryTerms> container with the
> > >GlossaryRefs to the other terms. These are the numbers at the end of each
> > >line in glossary.data. They are the ID numbers of the other glossary terms.
> > >Therefore, instead of reading in each line from glossary.data and 
> > >processing
> > >it, you will need to read it all at once and put it into an array, then 
> > >parse
> > >that array.
> > >
> > >EVERYONE PLEASE READ AND COMMENT:
> > >Currently the glossary.idx file contains a list of pages that contain each
> > >glossary item. This is created by an external script and is **not** done 
> > >when
> > >the glossary item is loaded. That would take way too much time. The 
> > >question
> > >is whether we should have PageRefs within the Glossary KU.
> > >
> > >Personally, I do not think so. We can create the index of  glossary-page_id
> > >along  with everything else. If we include the page ID/page name within the
> > >Glossary KU and add a new glossary item, then we would need to go looking 
> > >for
> > >all of the pages that have that glossary term. Obviously we need to search
> > >for the pages to add the <Glossary> tag within the page. However, I just 
> > >see
> > >it as unnecessary work to add PageRefs withing the Glossary KU since we can
> > >create the index by other, more efficient means.
> > >
> > >
> > >EVERYONE PLEASE READ AND COMMENT:
> > >It just hit me that we might be building a trap for ourselves. If we use 
> > >the
> > >full path instead of the ID number, we will have problems if we ever rename
> > >the file, move it to a different directory, etc. I **expect** to be moving
> > >files to different directories real soon! I want to change the order of the
> > >files and their locations. As we get more content, I can imagine that we
> > >change locations again.
> > >
> > >I see three options:
> > >
> > >Use the full-path as the PageRef:
> > >- Easy to find/insert the reference we want
> > >- Tracking down the actual page from a KU is easy
> > >- In the display code we don't need to do a look up to display the page.
> > >- PROBLEM: moving/renaming the file. Since the XML files are text, we can 
> > >use
> > >sed/perl to make a global change.
> > >
> > >Use just the page name without the path:
> > >- Once the file name is defined, it is less likely that the page name will 
> > >be
> > >changed.
> > >PROBLEM: We must have *completely unique* page names. We cannot have a 
> > >"Known
> > >Problems" in the Network section AND in the Printing section. They must be
> > >named "Known Problems-Network"  and "Known Problems-Printing" (or something
> > >like that).
> > >
> > >Use the ID as the PageRef:
> > >- Remains constant, independant of the actual name of the file.
> > >- PROBLEM: Need to do a look-up to find the correct file. However, since
> > >page.data is current sorted by chapter/section, I have found that  it is 
> > >not
> > >al that hard. For the existing moreinfo and DYK entries one PageRef can be
> > >inserted automatically. Still, if we want to include more PageRefs, we will
> > >hve to do it by hand and look up the ID, but we will have to look it up any
> > >way to get the full path. So whether we lookup and insert the page name or
> > >the page ID it's the same amount of work.
> > >
> > >I still like the idea of using the full-path and NOT and ID number. You 
> > >need
> > >to do a look-up anyway to find the ID or the correct text for the full 
> > >path.
> > >Tracking down the original page from the XML file is straight forward. 
> > >Making
> > >a change would be a simple matter of running a sed/perl script. We could 
> > >even
> > >write it in advance and it becomes a part of our "utility" package:
> > >
> > >rename_page.pl [-f filename] original_name new_name
> > >
> > >It then scans all PageRefs in the named file and changes them accordingly.
> > >
> > >Using an ID number bothers me because makes the construct dependant on an
> > >external file or we are imposing a structure on it unnecessarily. 
> > >Therefore,
> > >the knowledge base is not self-contained.
> > >
> > >EVERYONE PLEASE READ AND COMMENT:
> > >We have a similar problem with the MoreInfoRefs for the Page KUs. Currently
> > >they are referenced by their ID number and Luu did the same thing in her
> > >code. However, once again, I am not happy with idea of using ID numbers
> > >instead of text. So, do we reference the text of the MoreInfo KUs??
> > >
> > >I have pretty much decided to go through the existing data files and add up 
> > >to
> > >three topics. I will add these to the **end** of each line for all of the
> > >data files. So, Luu, could you change the code to create a <Topics> 
> > >container
> > >and <TopicRefs> for all of the data files? Note that I will probably not 
> > >list
> > >three topics for everything. Therefore, the code will need to be smart 
> > >enough
> > >to recognized this. Since you are probably asleep already I can work on it
> > >today and send you at least one file with the topics, so you will see the
> > >format.
> > >
> > >Regards,
> > >
> > >jimmo
> > >--
> > >---------------------------------------
> > >"Be more concerned with your character than with your reputation. Your
> > >character is what you really are while your reputation is merely what 
> > >others
> > >think you are." -- John Wooden
> > >---------------------------------------
> > >Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by: To learn the basics of securing
> > >your web site with SSL, click here to get a FREE TRIAL of a Thawte
> > >Server Certificate: http://www.gothawte.com/rd524.html
> > >_______________________________________________
> > >Linkbat-devel mailing list
> > >Linkbat-devel@...
> > >https://lists.sourceforge.net/lists/listinfo/linkbat-devel
> > 
> > 
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
> > http://join.msn.com/?page=features/featuredemail
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: 
> > Battle your brains against the best in the Thawte Crypto 
> > Challenge. Be the first to crack the code - register now: 
> > http://www.gothawte.com/rd521.html
> > _______________________________________________
> > Linkbat-devel mailing list
> > Linkbat-devel@...
> > https://lists.sourceforge.net/lists/listinfo/linkbat-devel
> -- 
> Shanta McBain <shanta@...>
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: 
> Battle your brains against the best in the Thawte Crypto 
> Challenge. Be the first to crack the code - register now: 
> http://www.gothawte.com/rd521.html
> _______________________________________________
> Linkbat-devel mailing list
> Linkbat-devel@...
> https://lists.sourceforge.net/lists/listinfo/linkbat-devel
-- 
Shanta McBain <shanta@...>

Re: [Linkbat-devel] Re: question on moreinfo.data (Everyone please read)

[Shanta McBain <shanta@fo...>]

On Wed, 2002-11-20 at 12:05, Luan Luu wrote:
> Hi All,
> 
> The seperator ":" is good for now in my opinion, since the other characters, 
> we will also have in some of the other data files.
> 

> The reason tag should be there and stay empty, not removed, because when you 
> extract XML to DB, i guess we expect a REASON tag to be there.
> 
> Is it possible the tyk.data file be modified a little bit?  Like you 
> mentioned, there are a couple of character in there which can not be convert 
> into valid XML format, such as the alone '&' need to change to '&', in 
> the line number 45.  The othere '&' in the data file was already in 
> converted format, so it is alright. only the previous one mentioned causes 
> problem. Also, I tried to convert all the < and > into the '&lt;' and '&gt;' 
> respectively.  Is that ok?
> 

This file is all ready converted to MySQL.
Add what ever field you like.
to see go to my devel site

http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat
Create an account and log in to see the link to the table.


> You mentioned the Topics and TopicRef tag should be insert into all the data 
> file?  Where do you think it should be?
> 
> For the new dyk.data.NEW you sent me, it would produce this.
> 
> <KnowledgeUnit>
>    <Attributes>
>       <Type>Concept</Type>
>       <Text>Linux can be started from any partition.</Text>
>    </Attributes>
>    <Pages>
>       <PageRef primary="true">106</PageRef>
>    </Pages>
>    <Questions>
> 
>    </Questions>
> </KnowledgeUnit>
> 
> Where should the topics and topicref goes?
> 
> thanks.
> 
> Best Regards
> -Luu
> 
> 
> 
> 
> 
> >From: James Mohr <linkbat-admin@...>
> >Reply-To: linkbat-admin@...
> >To: linkbat-devel@...
> >Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please 
> >read)
> >Date: Tue, 19 Nov 2002 11:03:51 +0100
> >
> >(Note this was sent to the list.)
> >
> >Hey everyone, the conversion is almost done (well, at least the code for 
> >it).
> >Thanks Luu! However, there are some important questions to answer NOW, 
> >before
> >we continue. PLEASE, please, please read this and give me your input.
> >
> >On Tuesday 19 November 2002 00:31, Luan Luu wrote:
> > > according the the moreinfo.data, the format:
> > > ID#:TYPE:DESCRIPTION:LOCATION
> > >
> > > the XML are
> > >
> > > <KnowledgeUnit>
> > > <Atrributes>
> > >   <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type>
> > >   <Text>[DESCRIPTION]</Text>
> > > </Atrributes>
> > > </KnowledgeUnit>
> > >
> > > In the reference to the brackets, is the pointer the the type, location,
> > > and description like that?
> >
> >Perfect. The only question is whether we should actually do it that way or
> >not. That is, should the sub-type and location be attributes within the
> ><Type> tag or should they be seperate tags, i.e. <SubType>  <Location>?
> >
> >By gut feeling is that they should be attributes within the  <Type> tag. 
> >They
> >not necessarily attributes of KU, but rather provide additional info for 
> >the
> >type.
> >
> >Comments anyone? This needs to be answered before we continue.
> >
> > > is the url be absolute path with the http infront right?
> >
> >Yes. You will note that in the data file, they just begin with // and not
> >http://. This was because I made an unwise decision to use the colon (:) as
> >the field seperator. However, the colon appears frequently in Linux
> >(especially with URLs) so it became a problem.
> >
> >I was going to change to something like a pipe (|) which comes less
> >frequently. Regardless, we will have a problem since the odds are that
> >whatever character we use, it will appear in text somewhere in the data.
> >
> >Obviously this is not a problem when we import directly into a database.
> >However, as I said to Shanta, I don't have a problem with importing the 
> >files
> >directly into a database for the first release. However, eventually I want
> >the system to be independant of the data source (CSV, database)  and
> >independant of the presentation (eXtropia, other portal).  Therefore, we 
> >need
> >to consider a new seperator.
> >
> >Suggestions?
> >
> > > Inside the tyk xml question tags, there is a topicRef tag, which is the
> > > reference of the PAGE_ID.  So, do you want to put the Page_id in the
> > > topicRef tags or the actual topic name in the page.data ?
> >
> >The TopicRef is a references to a topic, such as Administration, 
> >Networking,
> >Security, etc. This is just text. There are PageRef tags and these contains
> >the page *name* from page.data. However, I am nop longer sure we should do 
> >it
> >that way (see below). This needs to be changed in tykToXML.pl.
> >
> >Keep in mind that the questions will exist only within a KU. This KU will 
> >have
> >a primary page so we automatically have the primary page for the question.
> >However, the question could reference multiple topics.
> >
> >We have a problem with some of the questions where an angle bracket is one 
> >of
> >the answer ("What symbol is used to "pipe" two commands together?") This
> >means we have two angle brackets together (<< or >>) which could confuse 
> >the
> >XML parser. There are only a few and we can change them by hand. We just 
> >need
> >to be aware of them.
> >
> >Also watch the format of the answers, even for the T/F questions:
> >
> >         <Correct>
> >                 <Text>T</Text>
> >                 <Reason>why this answer is correct</Reason>
> >         </Correct>
> >
> >not just
> >
> ><Correct>T</Correct>
> >
> >I think that as much as possible it is better to have the same format for 
> >all
> >types of questions.  More than likely, "fill in the blank" type questions
> >won't have an <Incorrect> answer, but I still want to have a <Reason> tag 
> >to
> >provide an explanation why the answer is correct.
> >
> >However, since we do not yet have the reasons, I think you should simply 
> >leave
> >as <Reason></Reason>. I think if we leave the text as "put your reason why 
> >is
> >correct/incorrect. " we might forget to change it and then displaying that
> >text would look silly. If the <Reason> tag is empty, we can just ignore it.
> >OR we could simply not include the <Reason> tag at this point. What do you
> >think?
> >
> >With the Glossary KUs please create a <GlossaryTerms> container with the
> >GlossaryRefs to the other terms. These are the numbers at the end of each
> >line in glossary.data. They are the ID numbers of the other glossary terms.
> >Therefore, instead of reading in each line from glossary.data and 
> >processing
> >it, you will need to read it all at once and put it into an array, then 
> >parse
> >that array.
> >
> >EVERYONE PLEASE READ AND COMMENT:
> >Currently the glossary.idx file contains a list of pages that contain each
> >glossary item. This is created by an external script and is **not** done 
> >when
> >the glossary item is loaded. That would take way too much time. The 
> >question
> >is whether we should have PageRefs within the Glossary KU.
> >
> >Personally, I do not think so. We can create the index of  glossary-page_id
> >along  with everything else. If we include the page ID/page name within the
> >Glossary KU and add a new glossary item, then we would need to go looking 
> >for
> >all of the pages that have that glossary term. Obviously we need to search
> >for the pages to add the <Glossary> tag within the page. However, I just 
> >see
> >it as unnecessary work to add PageRefs withing the Glossary KU since we can
> >create the index by other, more efficient means.
> >
> >
> >EVERYONE PLEASE READ AND COMMENT:
> >It just hit me that we might be building a trap for ourselves. If we use 
> >the
> >full path instead of the ID number, we will have problems if we ever rename
> >the file, move it to a different directory, etc. I **expect** to be moving
> >files to different directories real soon! I want to change the order of the
> >files and their locations. As we get more content, I can imagine that we
> >change locations again.
> >
> >I see three options:
> >
> >Use the full-path as the PageRef:
> >- Easy to find/insert the reference we want
> >- Tracking down the actual page from a KU is easy
> >- In the display code we don't need to do a look up to display the page.
> >- PROBLEM: moving/renaming the file. Since the XML files are text, we can 
> >use
> >sed/perl to make a global change.
> >
> >Use just the page name without the path:
> >- Once the file name is defined, it is less likely that the page name will 
> >be
> >changed.
> >PROBLEM: We must have *completely unique* page names. We cannot have a 
> >"Known
> >Problems" in the Network section AND in the Printing section. They must be
> >named "Known Problems-Network"  and "Known Problems-Printing" (or something
> >like that).
> >
> >Use the ID as the PageRef:
> >- Remains constant, independant of the actual name of the file.
> >- PROBLEM: Need to do a look-up to find the correct file. However, since
> >page.data is current sorted by chapter/section, I have found that  it is 
> >not
> >al that hard. For the existing moreinfo and DYK entries one PageRef can be
> >inserted automatically. Still, if we want to include more PageRefs, we will
> >hve to do it by hand and look up the ID, but we will have to look it up any
> >way to get the full path. So whether we lookup and insert the page name or
> >the page ID it's the same amount of work.
> >
> >I still like the idea of using the full-path and NOT and ID number. You 
> >need
> >to do a look-up anyway to find the ID or the correct text for the full 
> >path.
> >Tracking down the original page from the XML file is straight forward. 
> >Making
> >a change would be a simple matter of running a sed/perl script. We could 
> >even
> >write it in advance and it becomes a part of our "utility" package:
> >
> >rename_page.pl [-f filename] original_name new_name
> >
> >It then scans all PageRefs in the named file and changes them accordingly.
> >
> >Using an ID number bothers me because makes the construct dependant on an
> >external file or we are imposing a structure on it unnecessarily. 
> >Therefore,
> >the knowledge base is not self-contained.
> >
> >EVERYONE PLEASE READ AND COMMENT:
> >We have a similar problem with the MoreInfoRefs for the Page KUs. Currently
> >they are referenced by their ID number and Luu did the same thing in her
> >code. However, once again, I am not happy with idea of using ID numbers
> >instead of text. So, do we reference the text of the MoreInfo KUs??
> >
> >I have pretty much decided to go through the existing data files and add up 
> >to
> >three topics. I will add these to the **end** of each line for all of the
> >data files. So, Luu, could you change the code to create a <Topics> 
> >container
> >and <TopicRefs> for all of the data files? Note that I will probably not 
> >list
> >three topics for everything. Therefore, the code will need to be smart 
> >enough
> >to recognized this. Since you are probably asleep already I can work on it
> >today and send you at least one file with the topics, so you will see the
> >format.
> >
> >Regards,
> >
> >jimmo
> >--
> >---------------------------------------
> >"Be more concerned with your character than with your reputation. Your
> >character is what you really are while your reputation is merely what 
> >others
> >think you are." -- John Wooden
> >---------------------------------------
> >Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by: To learn the basics of securing
> >your web site with SSL, click here to get a FREE TRIAL of a Thawte
> >Server Certificate: http://www.gothawte.com/rd524.html
> >_______________________________________________
> >Linkbat-devel mailing list
> >Linkbat-devel@...
> >https://lists.sourceforge.net/lists/listinfo/linkbat-devel
> 
> 
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
> http://join.msn.com/?page=features/featuredemail
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: 
> Battle your brains against the best in the Thawte Crypto 
> Challenge. Be the first to crack the code - register now: 
> http://www.gothawte.com/rd521.html
> _______________________________________________
> Linkbat-devel mailing list
> Linkbat-devel@...
> https://lists.sourceforge.net/lists/listinfo/linkbat-devel
-- 
Shanta McBain <shanta@...>

Re: [Linkbat-devel] Re: question on moreinfo.data (Everyone please read)

[Luan Luu <luu13@ho...>]

Hi All,

The seperator ":" is good for now in my opinion, since the other characters, 
we will also have in some of the other data files.

The reason tag should be there and stay empty, not removed, because when you 
extract XML to DB, i guess we expect a REASON tag to be there.

Is it possible the tyk.data file be modified a little bit?  Like you 
mentioned, there are a couple of character in there which can not be convert 
into valid XML format, such as the alone '&' need to change to '&', in 
the line number 45.  The othere '&' in the data file was already in 
converted format, so it is alright. only the previous one mentioned causes 
problem. Also, I tried to convert all the < and > into the '&lt;' and '&gt;' 
respectively.  Is that ok?

You mentioned the Topics and TopicRef tag should be insert into all the data 
file?  Where do you think it should be?

For the new dyk.data.NEW you sent me, it would produce this.

<KnowledgeUnit>
   <Attributes>
      <Type>Concept</Type>
      <Text>Linux can be started from any partition.</Text>
   </Attributes>
   <Pages>
      <PageRef primary="true">106</PageRef>
   </Pages>
   <Questions>

   </Questions>
</KnowledgeUnit>

Where should the topics and topicref goes?

thanks.

Best Regards
-Luu





>From: James Mohr <linkbat-admin@...>
>Reply-To: linkbat-admin@...
>To: linkbat-devel@...
>Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please 
>read)
>Date: Tue, 19 Nov 2002 11:03:51 +0100
>
>(Note this was sent to the list.)
>
>Hey everyone, the conversion is almost done (well, at least the code for 
>it).
>Thanks Luu! However, there are some important questions to answer NOW, 
>before
>we continue. PLEASE, please, please read this and give me your input.
>
>On Tuesday 19 November 2002 00:31, Luan Luu wrote:
> > according the the moreinfo.data, the format:
> > ID#:TYPE:DESCRIPTION:LOCATION
> >
> > the XML are
> >
> > <KnowledgeUnit>
> > <Atrributes>
> >   <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type>
> >   <Text>[DESCRIPTION]</Text>
> > </Atrributes>
> > </KnowledgeUnit>
> >
> > In the reference to the brackets, is the pointer the the type, location,
> > and description like that?
>
>Perfect. The only question is whether we should actually do it that way or
>not. That is, should the sub-type and location be attributes within the
><Type> tag or should they be seperate tags, i.e. <SubType>  <Location>?
>
>By gut feeling is that they should be attributes within the  <Type> tag. 
>They
>not necessarily attributes of KU, but rather provide additional info for 
>the
>type.
>
>Comments anyone? This needs to be answered before we continue.
>
> > is the url be absolute path with the http infront right?
>
>Yes. You will note that in the data file, they just begin with // and not
>http://. This was because I made an unwise decision to use the colon (:) as
>the field seperator. However, the colon appears frequently in Linux
>(especially with URLs) so it became a problem.
>
>I was going to change to something like a pipe (|) which comes less
>frequently. Regardless, we will have a problem since the odds are that
>whatever character we use, it will appear in text somewhere in the data.
>
>Obviously this is not a problem when we import directly into a database.
>However, as I said to Shanta, I don't have a problem with importing the 
>files
>directly into a database for the first release. However, eventually I want
>the system to be independant of the data source (CSV, database)  and
>independant of the presentation (eXtropia, other portal).  Therefore, we 
>need
>to consider a new seperator.
>
>Suggestions?
>
> > Inside the tyk xml question tags, there is a topicRef tag, which is the
> > reference of the PAGE_ID.  So, do you want to put the Page_id in the
> > topicRef tags or the actual topic name in the page.data ?
>
>The TopicRef is a references to a topic, such as Administration, 
>Networking,
>Security, etc. This is just text. There are PageRef tags and these contains
>the page *name* from page.data. However, I am nop longer sure we should do 
>it
>that way (see below). This needs to be changed in tykToXML.pl.
>
>Keep in mind that the questions will exist only within a KU. This KU will 
>have
>a primary page so we automatically have the primary page for the question.
>However, the question could reference multiple topics.
>
>We have a problem with some of the questions where an angle bracket is one 
>of
>the answer ("What symbol is used to "pipe" two commands together?") This
>means we have two angle brackets together (<< or >>) which could confuse 
>the
>XML parser. There are only a few and we can change them by hand. We just 
>need
>to be aware of them.
>
>Also watch the format of the answers, even for the T/F questions:
>
>         <Correct>
>                 <Text>T</Text>
>                 <Reason>why this answer is correct</Reason>
>         </Correct>
>
>not just
>
><Correct>T</Correct>
>
>I think that as much as possible it is better to have the same format for 
>all
>types of questions.  More than likely, "fill in the blank" type questions
>won't have an <Incorrect> answer, but I still want to have a <Reason> tag 
>to
>provide an explanation why the answer is correct.
>
>However, since we do not yet have the reasons, I think you should simply 
>leave
>as <Reason></Reason>. I think if we leave the text as "put your reason why 
>is
>correct/incorrect. " we might forget to change it and then displaying that
>text would look silly. If the <Reason> tag is empty, we can just ignore it.
>OR we could simply not include the <Reason> tag at this point. What do you
>think?
>
>With the Glossary KUs please create a <GlossaryTerms> container with the
>GlossaryRefs to the other terms. These are the numbers at the end of each
>line in glossary.data. They are the ID numbers of the other glossary terms.
>Therefore, instead of reading in each line from glossary.data and 
>processing
>it, you will need to read it all at once and put it into an array, then 
>parse
>that array.
>
>EVERYONE PLEASE READ AND COMMENT:
>Currently the glossary.idx file contains a list of pages that contain each
>glossary item. This is created by an external script and is **not** done 
>when
>the glossary item is loaded. That would take way too much time. The 
>question
>is whether we should have PageRefs within the Glossary KU.
>
>Personally, I do not think so. We can create the index of  glossary-page_id
>along  with everything else. If we include the page ID/page name within the
>Glossary KU and add a new glossary item, then we would need to go looking 
>for
>all of the pages that have that glossary term. Obviously we need to search
>for the pages to add the <Glossary> tag within the page. However, I just 
>see
>it as unnecessary work to add PageRefs withing the Glossary KU since we can
>create the index by other, more efficient means.
>
>
>EVERYONE PLEASE READ AND COMMENT:
>It just hit me that we might be building a trap for ourselves. If we use 
>the
>full path instead of the ID number, we will have problems if we ever rename
>the file, move it to a different directory, etc. I **expect** to be moving
>files to different directories real soon! I want to change the order of the
>files and their locations. As we get more content, I can imagine that we
>change locations again.
>
>I see three options:
>
>Use the full-path as the PageRef:
>- Easy to find/insert the reference we want
>- Tracking down the actual page from a KU is easy
>- In the display code we don't need to do a look up to display the page.
>- PROBLEM: moving/renaming the file. Since the XML files are text, we can 
>use
>sed/perl to make a global change.
>
>Use just the page name without the path:
>- Once the file name is defined, it is less likely that the page name will 
>be
>changed.
>PROBLEM: We must have *completely unique* page names. We cannot have a 
>"Known
>Problems" in the Network section AND in the Printing section. They must be
>named "Known Problems-Network"  and "Known Problems-Printing" (or something
>like that).
>
>Use the ID as the PageRef:
>- Remains constant, independant of the actual name of the file.
>- PROBLEM: Need to do a look-up to find the correct file. However, since
>page.data is current sorted by chapter/section, I have found that  it is 
>not
>al that hard. For the existing moreinfo and DYK entries one PageRef can be
>inserted automatically. Still, if we want to include more PageRefs, we will
>hve to do it by hand and look up the ID, but we will have to look it up any
>way to get the full path. So whether we lookup and insert the page name or
>the page ID it's the same amount of work.
>
>I still like the idea of using the full-path and NOT and ID number. You 
>need
>to do a look-up anyway to find the ID or the correct text for the full 
>path.
>Tracking down the original page from the XML file is straight forward. 
>Making
>a change would be a simple matter of running a sed/perl script. We could 
>even
>write it in advance and it becomes a part of our "utility" package:
>
>rename_page.pl [-f filename] original_name new_name
>
>It then scans all PageRefs in the named file and changes them accordingly.
>
>Using an ID number bothers me because makes the construct dependant on an
>external file or we are imposing a structure on it unnecessarily. 
>Therefore,
>the knowledge base is not self-contained.
>
>EVERYONE PLEASE READ AND COMMENT:
>We have a similar problem with the MoreInfoRefs for the Page KUs. Currently
>they are referenced by their ID number and Luu did the same thing in her
>code. However, once again, I am not happy with idea of using ID numbers
>instead of text. So, do we reference the text of the MoreInfo KUs??
>
>I have pretty much decided to go through the existing data files and add up 
>to
>three topics. I will add these to the **end** of each line for all of the
>data files. So, Luu, could you change the code to create a <Topics> 
>container
>and <TopicRefs> for all of the data files? Note that I will probably not 
>list
>three topics for everything. Therefore, the code will need to be smart 
>enough
>to recognized this. Since you are probably asleep already I can work on it
>today and send you at least one file with the topics, so you will see the
>format.
>
>Regards,
>
>jimmo
>--
>---------------------------------------
>"Be more concerned with your character than with your reputation. Your
>character is what you really are while your reputation is merely what 
>others
>think you are." -- John Wooden
>---------------------------------------
>Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: To learn the basics of securing
>your web site with SSL, click here to get a FREE TRIAL of a Thawte
>Server Certificate: http://www.gothawte.com/rd524.html
>_______________________________________________
>Linkbat-devel mailing list
>Linkbat-devel@...
>https://lists.sourceforge.net/lists/listinfo/linkbat-devel


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Linkbat-devel] question tb

[Shanta McBain <shanta@fo...>]

Humm Not sure why it is not picking up the CSSView. Have to go now so I
will work on it again later. May be just my browser. 

Shanta


On Wed, 2002-11-20 at 11:18, Shanta McBain wrote:
> the took 1.5 Hours to convert from CSV to MySQL and create a base app to
> access the data. 
> 
> eXtropia hacking at its best. Not every things gos that well though.
> 
> -- 
> Shanta McBain <shanta@...>
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: 
> Battle your brains against the best in the Thawte Crypto 
> Challenge. Be the first to crack the code - register now: 
> http://www.gothawte.com/rd521.html
> _______________________________________________
> Linkbat-devel mailing list
> Linkbat-devel@...
> https://lists.sourceforge.net/lists/listinfo/linkbat-devel
-- 
Shanta McBain <shanta@...>

Re: [Linkbat-devel] Questions Table

[Shanta McBain <shanta@fo...>]

Try question manager in the Admin add links I will add one to the admin
links.

Shanta

On Wed, 2002-11-20 at 12:31, James Mohr wrote:
> On Wednesday 20 November 2002 19:33, Shanta McBain wrote:
> > Hi All
> >
> > I have created the Questions table here is the details contained in the
> > Client news link on the left side bar this is only visible to
> > Linkbat_admin. I also have not converted this to the Linkbat View yet so
> > you will not get a left side bar or style sheets. (this is written with
> > View from the web)
> 
> I have three links labled "Client news". None of them provide any questions. 
> (At least nothing I have found.) 
> 
> >
> > Added Questions table
> >
> > Please note new addition in admin add table on the left side bar. This
> > link is to the table of questions. see details.
> >
> > The Question number no longer match the original table as the first
> > field in the MySQL table was set to auto incriminate so the table was
> > populated with a different set of numbers than the csv file. If this is
> > critical I can redo it. turning of auto inc then turning it on after
> > install.
> 
> The actual question numbers (i.e. question IDs) are not important. What is 
> important is the included page ID. This provides the link back to the page 
> where the this question came from. 
> 
> >
> > Another note of importance is the category field . The drop list of
> > entries are contained in a table and filled via a ActionHandler. This
> > allows admin to add new categories by placing them in the table. I am
> > currently updating this system and will add the changes soon. This will
> > consist of an add form in the admin add links and a ActionHandler tuned
> > to Linkbats needs.
> 
> I am missing the point of a form to input questions. I understand that this is 
> something that eXtropia can do, but unless this mechanism can insert the 
> question into a KU in the XML file and make the necessary references I am 
> missing the point. 
> 
> regards,
> 
> jimmo
> 
> -- 
> ---------------------------------------
> "Be more concerned with your character than with your reputation. Your
> character is what you really are while your reputation is merely what others
> think you are." -- John Wooden
> ---------------------------------------
> Be sure to visit the Linux Tutorial:  http://www.linux-tutorial.info
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: 
> Battle your brains against the best in the Thawte Crypto 
> Challenge. Be the first to crack the code - register now: 
> http://www.gothawte.com/rd521.html
> _______________________________________________
> Linkbat-devel mailing list
> Linkbat-devel@...
> https://lists.sourceforge.net/lists/listinfo/linkbat-devel
-- 
Shanta McBain <shanta@...>

[Linkbat-devel] question tb

[Shanta McBain <shanta@fo...>]

the took 1.5 Hours to convert from CSV to MySQL and create a base app to
access the data. 

eXtropia hacking at its best. Not every things gos that well though.

-- 
Shanta McBain <shanta@...>