Menu
▾
▴
ngoid-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Ashvil <as...@i3...> - 2000-05-17 16:29:35
|
If you signed up in digest mode, you will ONLY get ONE mail a day. If this was not your intention, please go to the bottom of the page at http://lists.sourceforge.net/mailman/listinfo/ngoid-dev enter your email address and click the 'Edit Options' button. and change the digest option to 'Off' on the next page. Regards, Ashvil |
|
From: Ashvil <as...@i3...> - 2000-05-17 01:38:46
|
Hi Chris, Chris Mollis <cm...@ob...> said: > Have you guys ever heard of Lore? It's an experimental XML database management system > from Stanford University... it let's you browse, search, and query XML databases (like > NGOID).. it allows you to take an XML stream from any source including URLs (it says).. > > check it out... http://www-db.stanford.edu/lore > Thanks for the link. I will take a look at it. I also send an email to Andre from Stanford to find out if Lore is avaliable under an Open Source license. I also invited Andre to help us with this project. Also, I found another Open Source XML database. http://www.ozone-db.org/ Regards, Ashvil |
|
From: Chris M. <cm...@ob...> - 2000-05-16 19:48:13
|
Have you guys ever heard of Lore? It's an experimental XML database management system from Stanford University... it let's you browse, search, and query XML databases (like NGOID).. it allows you to take an XML stream from any source including URLs (it says).. check it out... http://www-db.stanford.edu/lore ngo...@li... wrote: > Send Ngoid-dev mailing list submissions to > ngo...@li... > > To subscribe or unsubscribe via the web, visit > http://lists.sourceforge.net/mailman/listinfo/ngoid-dev > or, via email, send a message with subject or body 'help' to > ngo...@li... > You can reach the person managing the list at > ngo...@li... > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Ngoid-dev digest..." > > Today's Topics: > > 1. Indexing Criteria for Job Posting Service on this directory (he...@i3...) > 2. Re: Indexing Criteria for Job Posting Service on this directory (Ashvil) > > --__--__-- > > Message: 1 > From: he...@i3... > Date: Mon, 15 May 2000 22:19:15 -0700 (PDT) > To: ngo...@so... > Subject: [Ngoid-dev] Indexing Criteria for Job Posting Service on this directory > > Hello, > > As per my previous posting, I am working on defining a structure for a sample > application for Job posting that can be build on top of NGOID directory. I > have been doing some research and trying to identify minimum indexing > criteria that should allow companies to identify job requirements and should > be relatively easy enough for NGOID developers to build an initial sample app > on top. > Following is the representation of the minimum indexing criteria that I am > proposing. I would really appreciate any help and feedback from the community. > > Indexing Criteria: These are the fields that the publishing entity (users) > must provide information to in order for them to list jobs that can be > indexed and search by the application providers. Indexing criteria is a group > of fields that is part of info.xml > > Following is the simplistic view of indexing fields that I think we need to > go ahead with in order to develop a job posting app that can be used by > business entities. > > Idexing Categories for Job Posting application: > > I have tried to identify three different sets of indexing criterias. All > three are fairly important. The challange here is to choose one or two > simplistic criterias for the sample application. But, this choise should not > restrict the future flexibility of searching. As indexing strategy would have > an impact on search mechanism and flexibility. > I think the indexing criteria must be a combination of > 1) Job Category (Industry, Job Function, Sub Funbction etc.) > 2) Geographical Location > 3) Free Key words (Weighted key words that can be used in free form to > provide ultimate flexibility in defining the job and search criteria) > > 1 and 2 are relatively easy to define and implement, but number 3 (keyword > based) indexing scheme is the most critical and difficult to do. > Please review the following structure and advise if I am on the right track. > Please keep in mind, this excercise is a quick one in order to get some > sample demo app out there to demonstrate directory's vision. > We must then extend these definition and info.xml 'service' micro schemas to > support robust applications. > > Info.Xml > > <Identification Information> (Optional or Mendatory.. please refer to > info.xml) > </Identification Information> > > #Indexing Information: Index #1 > <Category> > example (Advertising / Marketing, Information Technology, Computer > SOftware, Accounting etc.) > <Sub Category> > These can be defined by domain experts. We should explode > atleast one domain for example (I would do IT domain) > </Sub Category> > </Category> > > #Indexing Information: Index #2 > <Country> > <State/Province> > <Location> > example (US-California-Silicon Valley, Work From Home, Travel etc.) > Other data fields that must be on the service (micro schema)are > </Location> > </State/Province> > </Country> > > #Indexing Information: Index #3 > <Keyword> > <Weightage> > </Weightage> > </Keyword> > <Keyword> > <Weightage> > </Weightage> > </Keyword> > <Keyword> > <Weightage> > </Weightage> > </Keyword> > > # Other Qualifying fields (Not part of an index) > <Job Level> (Entry Level, 2+ Years, 5 + Years, Mid Career, Executive) > </ Job Level> > > <City> > </City> > > <Job Title> > </Job Title> > > <Posittion Type> > Fill TIme, Part Time, ContrACT etc. > </Posittion Type> > > <More...> Need more input.... > > Thank you, > Hemant Asher > NGOID Member > > --__--__-- > > Message: 2 > Date: Tue, 16 May 2000 11:27:27 -0700 (PDT) > To: ngo...@so... > Subject: Re: [Ngoid-dev] Indexing Criteria for Job Posting Service on this directory > From: Ashvil <as...@i3...> > > he...@i3... said: > > I think the indexing criteria must be a combination of > > 1) Job Category (Industry, Job Function, Sub Funbction etc.) > > 2) Geographical Location > > 3) Free Key words (Weighted key words that can be used in free > form to > > provide ultimate flexibility in defining the job and search > criteria) > > > > 1 and 2 are relatively easy to define and implement, but number 3 > (keyword > > based) indexing scheme is the most critical and difficult to do. > > There is an article written on inverted indexing > http://hotwired.lycos.com/webmonkey/code/97/16/index2a.html > > The database used is Open Source. However, it looks like it had > Perl interfaces and the sample of the article is in Perl. Since > SourceForge supports PHP, we may need someone to port the Perl code > over to PHP. > http://www.sleepycat.com/ > > I think if we use a combination of hierarchial indexes and inverted > indexes along with issue of the context of the XML element, we > should have a killer search/indexing capability. > > Regards, > Ashvil > > --__--__-- > > _______________________________________________ > Ngoid-dev mailing list > Ngo...@li... > http://lists.sourceforge.net/mailman/listinfo/ngoid-dev > > End of Ngoid-dev Digest |
|
From: Ashvil <as...@i3...> - 2000-05-16 18:28:35
|
he...@i3... said: > I think the indexing criteria must be a combination of > 1) Job Category (Industry, Job Function, Sub Funbction etc.) > 2) Geographical Location > 3) Free Key words (Weighted key words that can be used in free form to > provide ultimate flexibility in defining the job and search criteria) > > 1 and 2 are relatively easy to define and implement, but number 3 (keyword > based) indexing scheme is the most critical and difficult to do. There is an article written on inverted indexing http://hotwired.lycos.com/webmonkey/code/97/16/index2a.html The database used is Open Source. However, it looks like it had Perl interfaces and the sample of the article is in Perl. Since SourceForge supports PHP, we may need someone to port the Perl code over to PHP. http://www.sleepycat.com/ I think if we use a combination of hierarchial indexes and inverted indexes along with issue of the context of the XML element, we should have a killer search/indexing capability. Regards, Ashvil |
|
From: <he...@i3...> - 2000-05-16 05:20:14
|
Hello,
As per my previous posting, I am working on defining a structure for a sample
application for Job posting that can be build on top of NGOID directory. I
have been doing some research and trying to identify minimum indexing
criteria that should allow companies to identify job requirements and should
be relatively easy enough for NGOID developers to build an initial sample app
on top.
Following is the representation of the minimum indexing criteria that I am
proposing. I would really appreciate any help and feedback from the community.
Indexing Criteria: These are the fields that the publishing entity (users)
must provide information to in order for them to list jobs that can be
indexed and search by the application providers. Indexing criteria is a group
of fields that is part of info.xml
Following is the simplistic view of indexing fields that I think we need to
go ahead with in order to develop a job posting app that can be used by
business entities.
Idexing Categories for Job Posting application:
I have tried to identify three different sets of indexing criterias. All
three are fairly important. The challange here is to choose one or two
simplistic criterias for the sample application. But, this choise should not
restrict the future flexibility of searching. As indexing strategy would have
an impact on search mechanism and flexibility.
I think the indexing criteria must be a combination of
1) Job Category (Industry, Job Function, Sub Funbction etc.)
2) Geographical Location
3) Free Key words (Weighted key words that can be used in free form to
provide ultimate flexibility in defining the job and search criteria)
1 and 2 are relatively easy to define and implement, but number 3 (keyword
based) indexing scheme is the most critical and difficult to do.
Please review the following structure and advise if I am on the right track.
Please keep in mind, this excercise is a quick one in order to get some
sample demo app out there to demonstrate directory's vision.
We must then extend these definition and info.xml 'service' micro schemas to
support robust applications.
Info.Xml
<Identification Information> (Optional or Mendatory.. please refer to
info.xml)
</Identification Information>
#Indexing Information: Index #1
<Category>
example (Advertising / Marketing, Information Technology, Computer
SOftware, Accounting etc.)
<Sub Category>
These can be defined by domain experts. We should explode
atleast one domain for example (I would do IT domain)
</Sub Category>
</Category>
#Indexing Information: Index #2
<Country>
<State/Province>
<Location>
example (US-California-Silicon Valley, Work From Home, Travel etc.)
Other data fields that must be on the service (micro schema)are
</Location>
</State/Province>
</Country>
#Indexing Information: Index #3
<Keyword>
<Weightage>
</Weightage>
</Keyword>
<Keyword>
<Weightage>
</Weightage>
</Keyword>
<Keyword>
<Weightage>
</Weightage>
</Keyword>
# Other Qualifying fields (Not part of an index)
<Job Level> (Entry Level, 2+ Years, 5 + Years, Mid Career, Executive)
</ Job Level>
<City>
</City>
<Job Title>
</Job Title>
<Posittion Type>
Fill TIme, Part Time, ContrACT etc.
</Posittion Type>
<More...> Need more input....
Thank you,
Hemant Asher
NGOID Member
|
|
From: Ashvil <as...@i3...> - 2000-05-09 18:31:43
|
Hi Hemant, he...@i3... said: > > an entitiy). I would appreciate any input from NGOID community members. Has > > anybody come across similar XML schema or structure or standard? > > Xml.org has a list of schemas http://xml.org/xmlorg_registry/index.shtml The HR-XML Consortium has developed three provisional schemas http://www.hr-xml.org/schemas.html You may want to contact the HR-XML Consortium and ask them if they can help. Regards, Ashvil |
|
From: <he...@i3...> - 2000-05-09 06:44:17
|
> Hello, > > I am currently working on defining a sample application to work on top of > Next Generation Open Internet Directory. We have selected a job posting > application that companies can use. Companies can publish their resource > requirements in an open format. APplication providers could build search > mechanisms or matching services on top. > > I am currently in the process of defining the data structure (mendatory and > optional) for the job posting service (as part of info.xml for the company as > an entitiy). I would appreciate any input from NGOID community members. Has > anybody come across similar XML schema or structure or standard? > > I am also working on publishing a MRD (Marketing Requirements Document) for > this application. I would publish these two pieces soon. Any input from the > community will be or a great help. > > THank you, > Hemant Asher > NGOID Community Member > -- |
|
From: Ashvil <as...@i3...> - 2000-05-01 23:00:41
|
We now have a page for the latest news. This will the place to get the latest news. http://www.i3connect.net/w-agora/news.html Based on feedback, we got, the project is split up into different technical modules. Each module owner is responsible for their area of the project. Current Module owners are XML Schema - Ashvil Indexing - Kris Registration - Mansi Search - Mansi Applications - Hemant We would like to break down these modules into more granular tasks and modules and also add more owners. If you can help in this process by suggesting new modules or adding tasks, please do. We are looking at using the bug list http://sourceforge.net/bugs/?group_id=4769 at Source Forge to coordinate all tasks in this project. Feel free to add more tasks to this list. Let me know your comments, suggestions, etc. We are still figuring out how to run this project ;-) Regards, Ashvil |
|
From: Ashvil <as...@i3...> - 2000-04-27 16:36:42
|
There is a new version of SOAP out http://develop.com/SOAP/ http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm For those who are unfamiliar with SOAP here is the official line : SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. It looks like this protocol may become a standard in the future. However, the standard looks to be in flux and there does not seem to be a lot of implementations of the protocol. We need a protocol that lets the Application servers query the indexing servers, for the Authoring servers to ask the indexing servers to index the data. There is another protocol called xml-rpc and the information is available at xml-rpc.com. This protocol is more widely supported and we should be able to use these modules directly. This would also benefit other people trying to talk to our indexing servers as they would be using a standard. I think we should consider using this atleast until SOAP becomes a standard and has lots of implementations. Comments. Suggestions. Anyone has experience or knows people who have used xml-rpc before ? Thanks to all the participants in this project. Regards, Ashvil |
|
From: <rwe...@ne...> - 2000-04-25 17:06:25
|
Ashvil wrote: > Rob wrote > > Yes, that is a useful thing and one which can be done > > without addressing the authentication and access control > > issues. But doesn't it imply that publishers will most > > likely be commercial entities (who would be publishing > > anyway and paying for their publishing), rather than "you > > and me and my mother"? More of a Yellow Pages than a White Pages. > > > > Rob > > > > Hopefully we can attract small biz folks, non-profit groups who want > volunteers, community web sites like xmlhack.com, Individual fan > sites, etc. where developers and other folks gather. If we can open up > the Yellow pages using an Open virtual database, where people can > search for their ideal job or look for some volunteer work. Right now > the yellow pages are controlled by major corporate entities anyway. > > The big commercial entities have their own publishing avenues, so I > doubt they will be interested at the start. If they want to sign up, > they are welcome, provided they honor the license to keep the data > open. > > I don't look at this as a Yellow pages vs. White pages issue, I think > the two concepts will merge, once we have a digital verification > system in place, That was the magic phrase I didn't dare use (digital verification)... If only PKI was universally available. > as small folks can get access to the same avenues as > big guys. After all, we all have something to sell, whether it our > skills or the stuff in the garage ;-) Sure, once everyone has digital certs, and also access to some registry for roles (like recruiter, travel agent). > > > Besides we need an application to help build the directory and this > one seems to be the easiest to start with, I hope. But that does not > mean all of us need to have a one track focus, Feel free to focus on > any tasks that help the project. I'm not arguing with that. I agree there is value there and that it is a good place to start. Rob > > > Regards, > Ashvil > > _______________________________________________ > Ngoid-dev mailing list > Ngo...@li... > http://lists.sourceforge.net/mailman/listinfo/ngoid-dev |
|
From: Ashvil <as...@i3...> - 2000-04-25 16:45:35
|
Rob wrote > Yes, that is a useful thing and one which can be done > without addressing the authentication and access control > issues. But doesn't it imply that publishers will most > likely be commercial entities (who would be publishing > anyway and paying for their publishing), rather than "you > and me and my mother"? More of a Yellow Pages than a White Pages. > > Rob > Hopefully we can attract small biz folks, non-profit groups who want volunteers, community web sites like xmlhack.com, Individual fan sites, etc. where developers and other folks gather. If we can open up the Yellow pages using an Open virtual database, where people can search for their ideal job or look for some volunteer work. Right now the yellow pages are controlled by major corporate entities anyway. The big commercial entities have their own publishing avenues, so I doubt they will be interested at the start. If they want to sign up, they are welcome, provided they honor the license to keep the data open. I don't look at this as a Yellow pages vs. White pages issue, I think the two concepts will merge, once we have a digital verification system in place, as small folks can get access to the same avenues as big guys. After all, we all have something to sell, whether it our skills or the stuff in the garage ;-) Besides we need an application to help build the directory and this one seems to be the easiest to start with, I hope. But that does not mean all of us need to have a one track focus, Feel free to focus on any tasks that help the project. Regards, Ashvil |
|
From: <rwe...@ne...> - 2000-04-25 15:48:36
|
Ashvil wrote: > Hi Rob, > > > I might want recruiters to find my info but > > not my current manager. And so on. > > > > That's an issue that most people we talk to, point out. It is a > complex issue due to a lack of any digital verification system on the > internet, which can verify that the entity is a qualified recruiter in > your example. > > We want to complete the directory and then tackle these hard issues. > There is information that has no privacy restrictions. eg. - Those > recruiters and other managers posting jobs, want that information to > be seen by as many people as possible. At this point, we think that > these kinds of applications make the most sense. > > The first application that we are thinking of is a job posting > database, where instead of posting jobs to specified sites. The job > poster could enter it on any site and this information would be > available to the entire community. > > Comments ? > > Regards, > Ashvil Yes, that is a useful thing and one which can be done without addressing the authentication and access control issues. But doesn't it imply that publishers will most likely be commercial entities (who would be publishing anyway and paying for their publishing), rather than "you and me and my mother"? More of a Yellow Pages than a White Pages. Rob > > > > _______________________________________________ > Ngoid-dev mailing list > Ngo...@li... > http://lists.sourceforge.net/mailman/listinfo/ngoid-dev |
|
From: Ashvil <as...@i3...> - 2000-04-25 15:02:30
|
Hi Rob, > I might want recruiters to find my info but > not my current manager. And so on. > That's an issue that most people we talk to, point out. It is a complex issue due to a lack of any digital verification system on the internet, which can verify that the entity is a qualified recruiter in your example. We want to complete the directory and then tackle these hard issues. There is information that has no privacy restrictions. eg. - Those recruiters and other managers posting jobs, want that information to be seen by as many people as possible. At this point, we think that these kinds of applications make the most sense. The first application that we are thinking of is a job posting database, where instead of posting jobs to specified sites. The job poster could enter it on any site and this information would be available to the entire community. Comments ? Regards, Ashvil |
|
From: Dustin C. <dco...@ht...> - 2000-04-25 14:28:06
|
This is just a test. Please do not reply. Thank you... |
|
From: <rwe...@ne...> - 2000-04-25 05:43:15
|
The design page lists (among others) the following issues: Privacy Issues - How do we prevent people from turning this into a SPAM database ? Security Issues - How do we ensure security of the data ? I would think most people (including myself) would want to make certain information available to certain consumers, and other information available only to others. For example, for the use case with the surfing vacation I might want to allow bonafide travel agents to know about my desired travel agenda, but I would rather not share that information with the local burglars. For the use case with the job search, I might want recruiters to find my info but not my current manager. And so on. I can't think of a way to allow somewhat fine-grained access control with authentication, without making the thing too cumbersome to be widely adopted. Rob |
|
From: Ashvil <as...@i3...> - 2000-04-23 18:40:36
|
ANN: Next Generation Open Internet Directory An Open Data/Source project I would like to announce the Next Generation Open Internet Directory An Open Data/Source project. We hope to build a virtual database of information that is open for everyone to use. More details are at http://i3connect.net. This is an application platform project that is using XML as a transfer format on top of HTTP. We are looking for help in the XML community to build up the core protocols for the directory. Xml-dev is looking to solve similar problems with the foreign names thread. We know that this is a big and maybe crazy effort, but as the old proverb goes: A journey of a thousand miles begins with a single step. I am happy to take the first step with the xml-dev community, a place where I learnt more about xml then anywhere else. But if they are any errors in the web site, thats my fault and should not reflect on the xml-dev community ;-) Thx, Ashvil |
