Fwd: Stakeholder Queries response
Naval Sarda
Hi Owen,
Developer has clubbed multiple emails of yours and responded as below. Please review.
Naval
-------- Forwarded Message --------
| Subject: | Fwd: Stakeholder Queries response |
|---|---|
| Date: | Mon, 5 Dec 2022 20:12:39 +0530 |
| From: | Sudarshana <sudar...@epicomm.net> |
| To: | Naval Sarda <nsa...@epicomm.net> |
| CC: | jitendras <jite...@epicomm.net>, kom...@epicomm.net, Balasaheb <balas...@epicomm.net> |
Hi Owen
Please check response given below inline in GREEN color.
Thanks
Sudarshana
Naval, the easiest question to answer is which stylesheet to apply, i.e., the most recent one, which is available at https://stratml.us/#Part2+ or, more specifically, https://stratml.us/forms/part2stratml.xsl
OK we will take this file to apply style on all files
In the future it would be good to give users view options, including, for example, PDF for printing and more pleasant viewing and perhaps also styled XML including mailto comment links (for which I already have a specialized stylesheet). However, that's beyond the scope of what I want to do in the query service right now. In the meantime, styling should not be hard coded into the query service.
We have to download and add the name of that style file in the styletag of all xml files. To make the style dynamic, we have to overwrite the file from that location.
I had not anticipated having to update the stylesheet references as part of this project. However, as a worthwhile project in its own right, I'm very open to prospects for:
a) applying the most recent stylesheet to all of the files in the collection, using the sitemap listing;
OK
b) placing the new files in a new folder on the stratml.us site (in which case I'd update my Google site-specific query feature to limit its scope to that folder).
OK
That raises the question of why both the plain XML and the styled renditions are being indexed in the query service. That should not be necessary. The search results listings should point to the original files wherever they reside on the Web, via their URLs plus the identifiers of the elements revealed via the queries. At present, the files are all on the stratml.us site but that is not the aim in the long run. Hopefully, plans and reports will be posted on the organization's own websites or other intermediary sites that they choose to use, e.g., Chris' StratNavApp. https://www.stratnavapp.com/PublicProjects
We are indexing original files only, styled renditions are only used for view functionality. To make the database of the xml files, we will need to keep that files on local folders where that program is running.
Also we are not just downloading and using those files as it is for indexing. There are several steps before making to suitable for indexing.
1. We have to the list of files from the sitemap.
2. Then need to download each file from the respective paths
3. Basic reformation of tags by manipulating tags from each file as discussed with you earlier.
4. Dividing all files in 2 folders as there are two types of files one has starting tag StrategicPlan and other has PerformancePlanOrReport, both needs to keep in separate folders for indexing.
All this process we had not anticipated earlier, while working on files we came to know these things after the analysis.
We had already spent lots of time to analyse and come to this conclution. That time was not included in estimations and again we have to repeat same process. At actual we had spent more than 24 hours. On an average we are charging only 24 hours. A script has to be written to accompolish this so that next time we have to do bulk import again, it will do above activities in one go with lesser time. UI for bulk import is not included in estimates.
I'm also concerned about the import capability and why it may take as much as 24 hours of effort to reimport the collection. That does not bode well for the sustainability of the service. I'll need to know more about that and what can be done to make it quick, easy, and relatively automatic to import files, as per tech requirement Goal 3: Ingestion - Support importation of StratML files, individually and in bulk.
Importing files through the UI will be not included in this scope. That will be another feature.
Note: The link on "Ingestion" is an example of the result the query service should provide, pointing to that goal on the aboutthem.info site.
Owen Ambur
https://www.linkedin.com/in/owenambur/
Naval, besides correcting the query logic to be more precise (e.g., with respect to Stakeholder Names), it also seems to me that applying the most recent stylesheet to all of the files in the collection may be the most important next step to get the query service working properly. Consistent with Raines' Rule #7, doing so would add value in and of itself, regardless of anything else that may or may not be done.
With respect to presentation of query results listings, the hyperlinks should point directly to the files wherever they reside on the Web, via their URLs plus the Identifiers of the relevant elements reveal by the queries. (The search results should not point to the query database itself. It is metadata, not the data/documents themselves.) The hyperlinks should probably open in a new brower tab so that closing it returns users to the previous tab showing the query results.
Ok we will open hypelink in new tab.
Because Values & Stakeholders don't have identifiers, the best that probably can be done is to link to the sections in which they appear, like this for Values. Linking to Stakeholders will be more complex since they may occur at three different levels of the schema: Organization, Goal, and Objective.
However, if the Stakeholder element is queried in conjunction with the Goal/Objective elements, the link should point to the Goal or Objective anyway. Indeed, as far as the hyperlink is concerned, that's probably fine even if only the Stakeholder element is queried by itself.
In that case, however, what should probably be presented in the query results listing is the Description of the Stakeholder &/or perhaps the Role Description. On the other hand, if that's too much complexity to take on at once, it could be deferred for consideration later, on the assumption that it is the descriptions of the goals and objectives that matter most, rather than the descriptions of the stakeholders.
With respect to the current collection, I'd probably leave those files where they are but a) create a new folder at stratml.us/docs, b) place the newly styled renditions there, and c) use Notepad to semi-automatically update my sitemap listing at https://stratml.us/sitemap.xml.
Yes please, create separate folder for new files. So that we will not needed to process all files again and again. Otherwise we will need to write a script to find out newly added files.
As previously indicated, I'll need to understand why the sitemap listing cannot be used to semi-automatically ingest files into the query service and why doing so may require so much time and effort.
We cant use files as it is because we need some restructuring and manipulating of some tags to make files compatible to work in BaseX db.
Joe Carmel developed Perl script using the sitemap to create the catalog at https://stratml.us/carmel/catalogsitemap.html I re-run it periodically to update the catalog. Aside from the opportunity to improve the presentation of the catalog, the biggest problem with the script is that it re-catalogs the entire collection rather than merely the files added or modified since it was last run.
Owen Ambur
https://www.linkedin.com/in/owenambur/
Naval, while a complete browse listing, like the one I am providing at https://stratml.us/drybridge/index.htm, is beyond the scope of what I'm aiming to do in the initial query service, please note that Ashley Berner was highly impressed to see her organization's plan presented in that context ... because it makes evident how much time and effort has been invested in the collection. (Andre Cusson's StratML stats page was also very useful in that regard.) Ashley's first question was about who maintains all of those files.
By contrast, she did not take the time to check out the query service prior to our televideo conference nor did she express any intent to do so. However, she did express interest in considering how StratML might be used to facilitate data collection and analytical capabilities in their ongoing research activities. While I don't expect any immediate results, it was a very enjoyable conversation and it highlights the opportunity to demonstrate how value can be derived from StratML files.
Currently we are using inbuilt function to search keywords as it gives result fast. That function makes array of all the words in the XML in each tag and compares whole words among that array. If you want to change the logic of searching keyword like above, we have to change and apply our own logic of searching. It may reduce the performance of response time. That logic will take time to implement. This logic will be useful for all below queries.
It would not be surprising if the most common queries were for the users' own names and/or organizations as stakeholders, particularly to keep track of objectives for which they are responsible. For example, a query on "Chris Fox" discovers 13 files but only because the logic currently retrieves stakeholders with either of those two names rather than just those whose names are exactly as indicated. The logic of the queries needs to be fixed in that regard.
The bottom line, however, is that I take my interaction with Ashley as cause to continue maintaining my hypertext browse listing unless and until its value can be replaced by something as good or better.
On the other hand, if we decide to apply the most recent stylesheet to all of the documents in the collection, I may stop posting the plain XML renditions and just go with styled XML plus PDF for those that are available in that format.
As I think Jeff knows, I'd love to be able to provide PDF renditions for all of them and I look forward to the day that might be feasible.
While I don't see reference to it at https://www.stratnavapp.com/, if memory serves me correctly, Chis' app also enables output in Word (.docx) as well as HTML format.
Kurt is looking into updating the StratML framework in oXygen. https://www.oxygenxml.com/doc/versions/25.0/ug-editor/topics/editing-stratML.html | https://github.com/oxygenxml/stratml Since StratML is XML, oXygen should be capable of opening and editing files made available via the query service.
Owen Ambur
https://www.linkedin.com/in/owenambur/
On Tuesday, November 29, 2022 at 12:49:28 PM EST, Owen Ambur <owen....@verizon.net> wrote:
Ashley, I'm looking forward to our conversation tomorrow.
In the meantime, if you get a chance, I invite you to check out the StratML-enabled query service on which Naval is working, at
The Full Text search capability has not yet been implemented and there are other bugs to be worked out, but if he can get them fixed, I plan to host it at https://aboutthem.info/
Among the >5K plans currently available in the database there are 688 goals and objectives referencing "education". As shown in the screen shot below, seven of them reference "Hopkins" as a stakeholder.
A query on the term "school choice" turns up 26 goals and objectives.
"Performance" is referenced in 377 and "standards" in 478.
A stakeholder query on your name turns up one hit but that's because the query conflates the names of Chris Berner and Ashley Pilipiszyn.
Gaya and I are working to convert the South Carolina agency accountability reports from Excel to StratML format. If we are able to do so, they will provide a good set of performance indicator data that is currently lacking in the StratML collection.
In 2018 I manually converted USCB's performance report, at https://stratml.us/carmel/iso/part2/SCUSCB2018wStyle.xml and Jeff is providing StratML-to-PDF conversion service, e.g., at https://stratml.us/metaformixis/SCUSCB2018.pdf
Several John Hopkins' plans are available in StratML format at https://stratml.us/drybridge/index.htm#JHU, including this one in which you are named as as stakeholder: https://stratml.us/carmel/iso/JHIEPwStyle.xml I guess that means it must not have been indexed in the query service yet. However, the term "curricula" is referenced in 24 plans currently available in the database.
Owen Ambur
https://www.linkedin.com/in/owenambur/
Naval, queries of the Stakeholder element on the terms "communities" and "community" turn up, resectively, 133 and 257 hits.
However, a query on the term "communit" turns up none. Logically speaking, the latter should retrieve all of those included in the other two.
A Google site-specific full-text query turns up about 727 hits on "communit".
I'll look forward to learning about the logic that is currently being applied to the StratML-enabled queries and how much time and effort might be required to correct it.
As per my previous message, another problem with the logic is that when a stakeholder name has two (or more) parts queries currently return hits for each of them rather than just those conforming exactly to the query.
Owen Ambur
https://www.linkedin.com/in/owenambur/
Thanks & Regards
Sudarshana
Owen Ambur
a) place the new files with the most current stylesheet reference in a new folder (e.g., stratml.us/docs) on the StratML.us site,b) update my sitemap listing to point to those copies, andc) index those files in the query service.
Naval Sarda
Hi Owen,
We had proposed a mockup for importing StratML files before
starting this phase and you had deferred it into phase 2. It looks
like it is now a priority. We can essentially expose a UI which
will call the backend code to import the files individually /
bulk. We have not estimated about this UI and integration with
backend code.
Regarding the second part of applying most recent stylesheet, we
have already quoted 24 hours which will cover point a) and point
c) mentioned by you below.
Updating your sitemap, which is point b below, will need some
access to your existing sitemap so that we can figure out how we
can update the same.
Regarding updating stylesheets by yourself, we would like to know if you want to change the stylesheet for each and every record separately. Right now we have planned and estimated for applying one stylesheet for all the records in your sitemap.
We did start thinking about providing you some options to update sitemap. That discussion is still pending. We did receive one feedback from you from the options proposed. Then we thought, it will be better to provide query service so that you can reach individual entry easily through query service and then hit edit option.
I suppose you will need Organisation search field to reach quickly to the individual entry.
I suppose you might not need to maintain sitemap separately in
case you start liking query service and query service will lead
you to individual record from where you can edit.
Naval
Owen Ambur
Hi Owen,