MLS for the individual

Can anyone point me to a place that has the format and fields available in the files output from MLS?
If the testdata is not ready available then at least the list of fields in each file as we dont have MLS installed.

There seem to be a vast amount of applications out there to assist the functionality of the MLS system and no doubt more will arrive.
I am myself seriously thinking about creating an application to help in certain areas. I am well aware of the security issues with membership data and the grey areas and so on this issue I have emailed Tom with my suggestions for how I would deal with sensitive data. Its possible to be much more secure than most people would be with a CSV file on the laptop or typed out reports in their briefcase.

To give you a bit more information about my thoughts:

My main aim with the application would be to be MLS for the individual members and help them serve in their calling. Some of the functionality might simply be a link to lds.org or other useful site. Other functionality might have to be written separately.
Another major focus would be to assist leaders (in their calling) when attending meetings.

We cannot all be graduated project managers in the church and used to keeping check of all tasks and so my aim would be to let the program keep check of actions taken at the various meetings and for these to be visible via the application to both the person assigning and the person assigned to.

It would therefore also help put together an agenda and put an end to 'meetingitis" and hopefully help prevent meeting actions being lost in space because of lack of "follow up".

I see great potential for this particularly in small units where calling an Exec Sec and having two counsellors is a luxury. Having presided over and attended countless Branch Presidency, PEC & Branch Counsel Meetings I see real potential here for all involved.

There are other areas where I see potential but more about that in v2 (releasing and calling people). For now I am just interested to see what kind of information is available for output in MLS to work out what would be stored locally encrypted and what could be transfered encrypted via the net as well as working out what functionality is not worthwhile doubling up on if MLS already supports it.

dkjorgi wrote:Can anyone point me to a place that has the format and fields available in the files output from MLS?
If the testdata is not ready available then at least the list of fields in each file as we dont have MLS installed.

I'm a bit confused about how you propose to use "files ouput from MLS" at all if you don't have MLS installed.

boomerbubba wrote:I'm a bit confused about how you propose to use "files ouput from MLS" at all if you don't have MLS installed.

The purpose for creating the program is not just for us but for everyone elsewhere.
Importing from MLS wouldnt be a requirement but it would help a lot to get started.
If we had MLS installed here I could have got files from that and wouldnt have needed to ask for the format.

I hope that explains it better.

dkjorgi wrote:The purpose for creating the program is not just for us but for everyone elsewhere.
Importing from MLS wouldnt be a requirement but it would help a lot to get started.
If we had MLS installed here I could have got files from that and wouldnt have needed to ask for the format.

I hope that explains it better.

I guess I don't understand who you mean by "we." Are you a leader or clerk for a unit that does not use MLS?

In any case, I know of nothing in the MLS export files that relates to your idea about meetings and tracking action items from those meetings. If you want to build an application to do that, you might as well build it standalone, without reference to MLS. Since this is a generalized problem that obtains with anyone's meetings in any organization, there might well be generic software to do what you suggest.

A little something to chew on:

From the .pdf]Policy and Guidelines for Computers Used by Clerks for Church Record Keeping

"The assistant stake clerk assigned to manage Church computers has the following responsibilities. He: [...]

12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software."

In all fairness, item #11 reads: "Ensures that ward clerks do not install Church record-keeping software on their home computers and that they do not reverse-engineer record-keeping software code."

We have since learned in this forum that it's acceptable to install the software, just not the membership data. I'm not completely sure what the concern about item 12 is or where the line would be between an electronic copy (such as what's printed by the Palm export) and what would be "record keeping software". I could speculate (I'm good at that ), but it would be just that - speculation.

RussellHltn wrote: I'm not completely sure what the concern about item 12 is or where the line would be between an electronic copy (such as what's printed by the Palm export) and what would be "record keeping software". I could speculate (I'm good at that ), but it would be just that - speculation.

If I have learned anything from exploring such issues on this forum, it is that published Church "policy" in such matters is sometimes ambiguous, out-of-date, or contradictory, and that we who hope for clarified policies will be waiting a long time indeed.



Meanwhile, one might consider how Adam and Eve felt;

1. Don't eat that fruit!
2. Be fruitful and multiply!

RussellHltn wrote:A little something to chew on:

12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software."

I could speculate (I'm good at that ), but it would be just that - speculation.

Russell, I am not sure where you are going with this. If we are to interpret it the way you are leading up to (by mentioning it at all in the context of my original question) then one has to ask itself why the option to export such sensitive data is there in MLS in the first place.

#12 is very ambiguously described. It could even sound like it would prevent me from doing my day2day job
On the other hand, why are priesthood leaders prevented from developing?
Would my software be ok as I want it to be freeware?

If I had to guess then I would read #12 together with #11. I get the feeling that it means we ought not to profit for creating other software by tearing apart MLS and knowing what is going on in there. Maybe I am wrong.

All I know is I am keen to plug a gap where I see potential and at the same time also tighten up security of the data stored. Needless to say that any security on a desktop application is better than having the CSV export files from MLS sitting on a Palm or PC.

dkjorgi wrote:#12 is very ambiguously described. It could even sound like it would prevent me from doing my day2day job
On the other hand, why are priesthood leaders prevented from developing?
Would my software be ok as I want it to be freeware?

If I had to guess then I would read #12 together with #11. I get the feeling that it means we ought not to profit for creating other software by tearing apart MLS and knowing what is going on in there. Maybe I am wrong.

Although #12 doesn't specifically mention Church software, any reasonable interpretation of the context of the guidelines would acknowledge that the prohibition on the use of "tables, schemas, and the like" means you may not use the tables and schemas that underly Church software. Your day job that may use other tables and schemas (as does mine) is still just fine with the Church.

The prohibition on "third-party" software means it doesn't matter if it is free or not -- it is prohibited if it uses the underlying structure of MLS. I'm sure clerks and priesthood leaders are prohibited, as there is an assumption that they are the ones with access to MLS; the spirit of the guideline means that everyone else in the world is similarly prevented from freelance development based on the underlying tables and schemas.

But some wonderfully innovative and helpful tools have been created based on the established export files, and I see nothing in the guidelines that prevents such software development, as long as privacy and security of the data is properly maintained.

dkjorgi wrote:Russell, I am not sure where you are going with this.

I'm not sure either. But it's written policy and seems to touch on what you are doing. It's a point that I thought should be tossed out for discussion. Isn't it better that this is worked out before you start coding rather then after?

As for what it means, is it a prohibition against anything that reads the MLS database directly? Is it to insure that MLS is THE record keeping software of the unit and that it not be replaced by something else? If that's the case, then I don't see a problem with what you are doing.

But if it's something against "third party record keeping software" then that's something to think about. It's one thing to use the export as a computerized printout - to be able to search and find the information needed. But if this application collects and stores additional information, then it might be viewed as something that might be prohibited.

As far as what kinds of notes are kept, based on another thread about record keeping, it's one thing to have the equivalent of a "area book" where missionaries pass a set of notes to their replacements. It's quite another to have a dossier on members that is passed around between ward leaders. You might want to carefully consider what information your application will collect and how it will be stored or distributed. Free-form notes could be abused, but a check box for "follow-up with Home Teachers" would be safe.


But, there's a bigger problem. According to this thread, CSV files will be done away with and replace with vCard. I wouldn't think about doing anything until that's settled.

RussellHltn wrote:12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software.....

I had read that document online, though I wasn't sure what it means exactly. Since I am not in that calling, I don't have to interpret its definition of the job description. Alan_Brown's reading of the language seems reasonable to me -- the "tables and schemas" are a reference to the underlying data structures of MLS itself.

It does seem that the language could not have been intended to refer to the export files, or those export files would not have been provided as they have been for years. Such a reading would thus be absurd. Yet quite obviously each .csv file is logically a table, and there is an implicit schema -- albeit a technically klunky schema -- that relates them.

Alan_Brown wrote:Although #12 doesn't specifically mention Church software, any reasonable interpretation of the context of the guidelines would acknowledge that the prohibition on the use of "tables, schemas, and the like" means you may not use the tables and schemas that underly Church software.

I agree with you. Its very possible the thinking behind this here is to ensure no third-party writes to those files and thus potentially cause a lot of damage. My questions (with a smile) were merely to highlight many things can be interpreted in many different ways. Someone mentioned the situation around Adam and Eve which is always a good one.

boomerbubba wrote:It does seem that the language could not have been intended to refer to the export files, or those export files would not have been provided as they have been for years. Such a reading would thus be absurd.

I totally agree with you here.

RussellHltn wrote:I'm not sure either. But it's written policy and seems to touch on what you are doing. It's a point that I thought should be tossed out for discussion. Isn't it better that this is worked out before you start coding rather then after?

I think its well worth mentioning. Part of my original email said I would pass on my idea and approach to Tom Welch and his team to ensure I wasnt going into an area with an approach that the church would feel uneasy about. I think thats a better approach. Ironically the security side I think will heavily impact both development time but also installation for those who wish to use it in multi-user mode so no doubt first version will just be single-user.

RussellHltn wrote:As for what it means, is it a prohibition against anything that reads the MLS database directly? Is it to insure that MLS is THE record keeping software of the unit and that it not be replaced by something else? If that's the case, then I don't see a problem with what you are doing.

Thats also how I think about it. Its in the church's interest to ensure data integrity and make sure noone else reads or writes to it directly.

RussellHltn wrote:But if it's something against "third party record keeping software" then that's something to think about. It's one thing to use the export as a computerized printout - to be able to search and find the information needed. But if this application collects and stores additional information, then it might be viewed as something that might be prohibited.

I am thinking that "third party software" here is in the context of reading the church schema files directly. As for storing additional information I cannot see what the church would have against that as its no different to a typed up word document with sensitive information which surely must be something which is done a lot.

RussellHltn wrote:As far as what kinds of notes are kept, based on another thread about record keeping, it's one thing to have the equivalent of a "area book" where missionaries pass a set of notes to their replacements. It's quite another to have a dossier on members that is passed around between ward leaders. You might want to carefully consider what information your application will collect and how it will be stored or distributed. Free-form notes could be abused, but a check box for "follow-up with Home Teachers" would be safe.

Free-form notes I cant see the problem with as I believe a Word document is just as much of free format so a careful person will continue to be careful. What I do agree with you about is how this data is distributed. That is not an area to be taken lightly. My initial thoughts was to let some of the control go through the Bishop and any data transmitted would need to be encrypted and also with the possibility of using public and private keys.
I do think some training to the end-user here would be a good idea to emphase common sense in what is recorded.

Personally I think websites like those who are recording HT/VT and DutyToGod are touching the boundaries of what I personally feel comfortable with but then again I dont know how heavy their data is encrypted. It's not an area I will take lightly. But as I said that conversation I think is one which is better to take up with Tom and his team rather than the forum.
If I was they creator of those sites I would donate the work to the church so the data can rest on church servers. Just think of the blessings :rolleyes:

RussellHltn wrote:But, there's a bigger problem. According to this thread, CSV files will be done away with and replace with vCard. I wouldn't think about doing anything until that's settled.

I dont think that will affect my ideas. Its just another way of expressing data. vCard has in fact more potential for syncronising additional data. This all depends on which version of vCard the church will use and also how much of vCards functionality it will make use of. One thing is for sure, it wont be less than CSV format :rolleyes: (unless they limit the fields they are already exporting). vCard is pretty good if you want to write something that can syncronise two calendars as it is easy to express changes.

What I did ponder upon was more why the church decided to do away with the CSV format in the next version. If its coming back in later versions then maybe it was a simple "upps".

dkjorgi wrote:If I was they creator of those sites I would donate the work to the church so the data can rest on church servers. Just think of the blessings :rolleyes:

It's not that easy; the church won't just take them and put them on Church servers. It's been tried before, and the offering was denied.

After reading over this thread, I still have no clear idea about who the original poster represents or what his idea is.

The original title is, "MLS for the individual." That concept seems to have little to do with MLS, which is primarily designed for leaders. And the MLS exports are quite closely held, requiring administrator authentication and presumably bishop's approval. There are several outside helper applications that have been developed based on such exports, which generally are designed for leadership use. If the application -- yet to be invented or defined-- is similar to those, then that's one class of application I can understand. There is room for inventing better mousetraps in that field.

By contrast, one can gain a rough idea of what data Church authorities consider appropriate for general distribution to rank-and-file members -- the data that is displayed in the LUWS today. Although that may evolve around the margin, it is obviously a limited subset. If a developer wants to invent a helper app for all members, he could focus on that data, much of which is easily downloaded for one's own unit already. No MLS export or documentation s required.

mkmurray wrote:It's not that easy; the church won't just take them and put them on Church servers. It's been tried before, and the offering was denied.

Is there a chance you could elaborate on the challenges associated?
Was the offering not unconditional? Was the code unmaintainable? Technology not what you develop in? Too much work to implement own security framework?
Something else?

For the last 12 years I have myself been involved in the technical challenges associated every time our company has decided to grow organically by buying 3rd party products and leave it to us to create the magic to merge these in with our existing main product. All of the above questions are challenges we have faced. Buying 3rd party, creating open source, establish community effort, outsourcing or increase own resources are all possibilities but neither are without its challenges. Maybe if you explained further it would help us to understand the unique position the church might be in.

dkjorgi wrote:Is there a chance you could elaborate on the challenges associated?
Was the offering not unconditional? Was the code unmaintainable? Technology not what you develop in? Too much work to implement own security framework?
Something else?

...

Have you read the following thread? It is about the HT/VT reporting site and has a lot of information about the efforts made to get the Church to take it and put it to use:

http://tech.lds.org/forum/showthread.php?t=502

rmrichesjr wrote:Have you read the following thread? It is about the HT/VT reporting site and has a lot of information about the efforts made to get the Church to take it and put it to use

Thanks for pointing me in the direction of that thread. Thats given me good insight into what has happened so far in the forum.

I think its an incredible existing time ahead now that the church is considering how to take the purpose of this forum forward.

For 12 years I have worked on 4 commercial products within the same company and their strength have always been their ability to allow 1000+ 3rd party developers to write their own add-ons through API's etc.

Its no small task to get it right (we are still fine-tuning) so I dont envy the church team on embarking on this mission into the unknown.

It WILL take time so we just need to be patient.

dkjorgi wrote:For the last 12 years I have myself been involved in the technical challenges associated every time our company has decided to grow organically by buying 3rd party products and leave it to us to create the magic to merge these in with our existing main product. All of the above questions are challenges we have faced.

dkjorgi,

You have not responded upthread when I gently asked who you refer to by "we" or "us." I gather from the context here that you are referring to a company. Although you seem to be proposing to develop some software without fee, it is rather basic for the rest of us to know whom you represent. I undersand that information-technology companies might have business models that include providing free services for a variety of reasons, but they are still companies with business models.

Most conversations on this forum are among individual members seeking to magnify their callings, and expand the Church's technology horizons in the process. (When I say "we" in a post, I usually mean my ward or my ward leadership. That is what I typically see in other members' posts, too.)

You started this thread asking, "Can anyone point me to a place that has the format and fields available in the files output from MLS?" By this I gathered that you were referring to the export files.

If you follow the links in the thread above, and the links in the linked pages, I think in short order you will find all the published information that this community has available to it regarding those details. Such details are incomplete, but they are what they are. (Actually, for whatever reason the Church does not even fully document the export file layouts and data dictionaries even to those in leadership or clerical callings who admnister MLS installations -- the authorized users of such export files. You should not be surprised if neither the Church nor members of this forum will publish further details here or provide them to a third-party company offline.)

boomerbubba wrote:dkjorgi,

You have not responded upthread when I gently asked who you refer to by "we" or "us."

For that purpose I was refering to my day job and the company I work.. I just found it interesting to realise that in many aspects what we (me and the company I work for) have faced of challenges to involve 3rd party developers access to our product data in order for them to create their own add-on's are similar to the situation the church is facing now by involving the wider church community. In another comment I also mentioned the challenges we (me and the company I work for) had faced from merging some 3rd party products into our main product.

I therefore sympatise and understand why it can seem to take so long to get things in motion.

boomerbubba wrote:Most conversations on this forum are among individual members seeking to magnify their callings, and expand the Church's technology horizons in the process.

That is the same reason I am here. My ideas about the task functionality alone are born out of the experience gained from presiding over and attending countless WCM, PEC and presidency meetings.
Any project manager should know how to deal with and organise tasks and actions. While most local church leaders may be excellent leaders they are not always born to be pro's in task management and therefore I see real potential to assist them in keeping track of these things. It is all about having it visually available to them at all times an making sure no ideas or actions get lost.

I think the HT/VT product that one Brother did was a great example of seeing a need and then get the wheels in emotion within church to take it forward.

I understand his frustration at the waiting time but thats unfortunately the nature of it in many similar situations, also outside the church.

I also understand his frustration at the potential of having to let go of his own "baby" but that too is also very normal within the industry of I.T.

I have had to do it myself with ideas and products I have started as well as the opposite of taking on product/ideas from others.

It is the same within church when we serve in callings. We might have started and put in place a project or kickstarted something and then only to be released shortly after. We can probably also all recall the same things happening all the time on our missions with investigators when we were transfered.

I think its great as it gives the Lord a chance to use us where he feels we can serve best and then also allow others to take onboard what we have started.

At all times we must remember why we are doing it.

boomerbubba wrote:You started this thread asking, "Can anyone point me to a place that has the format and fields available in the files output from MLS?" By this I gathered that you were referring to the export files.
If you follow the links in the thread above, and the links in the linked pages, I think in short order you will find all the published information that this community has available to it regarding those details. Such details are incomplete, but they are what they are.....

I am very grateful for your comments, links etc. It is not vital I have those layouts. It would have made things easier for the end-users but if I must I can live without them. By the time I have completed my application ideas the availability of this and the policy surrounding them might be clearer.