-
Notifications
You must be signed in to change notification settings - Fork 3
Home
from March 2021 onwards
Present: Jo Cook, Peter Parslow, James Reid, Edd Lewis
Apologies: Colm Walsh
We clarified the actions on a couple of long-standing issues then focused on the issues marked as "to review" in the project. Several issues were confirmed as resolved, often as part of work on other issues.
- Issues 61 and 17 have an agreed text and are therefore moved to "to implement"
- Issue 96 is now merged and therefore moved to "completed"
- Jo to check that issues in "completed" are actually in live and can therefore be closed
- Issue 6 has been resolved while resolving other issues so has been closed and removed from the project
- Issue 21 needs input from James Passmore so has been parked
- Issue 59- guidance on using DOI as a resource identifier to be strengthened
- Issues 104, 64 and 82 are confirmed as resolved and therefore closed
- For Issue 26 the way forward was agreed but from an implementer's perspective it will imply some development work (though it's non-breaking) so it has been tagged as a release issue
Present: Jo Cook, Peter Parslow, James Passmore
Minutes not taken
Present: Jo Cook, Peter Parslow, Colm Walsh, James Passmore, James Reid Apologies: Michael Tink
- DD3 R7. Where possible, add Schema.org “corresponding element” entries to GEMINI elements #41 @PeterParslow to update table, then @archaeogeek to update elements with equivalent mappings, also publish this table as guidance. Issue moved from To do to In Progress
- (an attendee Geospatial Commission Data Discovery project workshop 28 Nov 2020) Suggestion we explicitly default the metadata to CC-0 (or equivalent) #26 This might be better as guidance rather than an explicit instruction. Assigning to James Passmore with assistance from Peter Parslow to create initial page
- 2021-02 Query about multiplicity of Limitations on Public Access/Use Constraints (Sean Gaffney, MEDIN) Better examples of different otherconstraints elements are required! Everyone to add examples so we can discuss and pick the most representative
- Discussion to clarify interpretation of Limitations on Public Access and Use Constraints #61 Jo Cook to have a go at an initial form of words for the guidance to take into account both this issue and https://github.com/agiorguk/gemini/issues/17. An example encoding will be needed too
https://github.com/agiorguk/gemini/pull/148 represents changes made to the dev site and branch since November 2023 that can now be published to the Live site. Peter Parslow has reviewed and approved this and updated the Change Log summary. (Merged 2024-05-13)
Present: Jo Cook, Rob Walker, Michael Tink
No issues changed- we just introduced Michael to the project and described how things work
Present: Jo Cook, Peter Parslow, Rob Walker, Colm Walsh
DD3 R1 Introduce GEMINI in the context of wider principles #31
- A new intro page has been written and published to live (https://agiorguk.github.io/gemini/1037-uk-gemini-introduction.html) and the link from the main AGI website (https://www.agi.org.uk/uk-gemini/) now points to that page
2020-25 Conformity specification date (INSPIRE Validator; Peter) #12
- Moved to to implement
- @archaeogeek to change guidance point 1 to "shall" rather than "must" and remove references to services
- @archaeogeek also to review services guidance
Spatial reference system: encoding example with authority - is this still valid? #28
- Moved to to implement
- @archaeogeek to change description for example three in https://agiorguk.github.io/gemini/1062-gemini-datasets-and-data-series.html#17 to "Example Three - encoding example with ISO 19115 authority, as generally described Extended metadata/additional elements"
- This issue has been published to dev and awaits publication to live
- Moved to for review
DD3 R14 Alternative title: guidance #50
- This issue has been published to dev and awaits publication to live
Present: Jo Cook, Peter Parslow, Rob Walker, James Reid, James Passmore
2020-28 Spatial resolution preferred over Equivalent scale (Sean Gaffney, October 2020)
- James encountered an issue with the DGU CSW endpoint so was unable to test this (which may have since been fixed)
- If not, Jo to send SSDI CSW to James for testing
2020-13 Text for guidance on use of service metadata elements (from Sean, April 2020)#3
- Jo created new issues but forgot to add them to the project so she will do that
2020-25 Conformity specification date (INSPIRE Validator; Peter)
- Peter to do a PR
- Peter to do a PR
Request to register an additional GEMINI profile
- Initial issue is out of date
- Jo to close and create new guidance issue- actually Jo edited the title to keep the discussion
2020-31 ISO 19139 Code list locations
- Peter to do a PR
How to manage & publish GEMINI pages
- Jo to add link to the documentation for publishing and get someone new (eg who hasn't already made some changes) to review
Document (and possible change) the GEMINI versioning/release rules
- Jo to reword Principle 3
- James P to do some new guidance on use of personal names vs role names in contact or point of contact
- Peter to produce a new page showing UK Regulations, plus link to it from the element guidance
- This requires a guidance change plus a check in the optional schematron
AOB: Move to meetings every 2 months (therefore cancelling December meeting)
Present: Jo Cook, Peter Parslow, Colm Walsh, James Reid, James Passmore, Rob Walker, Edd Lewis
Prelims:
- The work to move the Gemini documentation to GitHub is now complete. Links from the AGI website forward to GitHub. We can now move forward with addressing the issues that are outstanding in the project. Yay!
- All items in this board are to be reviewed since they may well have been included in the version that is now live. Those that have been included in the live site can be closed or moved to a review column
- This board can then be closed or renamed as needed
ACTION:
- Peter to review
- All issues in this board need an editorial check (as above)
ACTION:
- Peter to review (I think...)
2020-28 Spatial resolution preferred over Equivalent scale (Sean Gaffney, October 2020)
- As per the discussion on the issue this is a breaking change (sort of) but the impact could be lessened by moving the new rule into the supplemental schematron where it should be handled as a report rather than a validation failure.
- Guidance to be strengthened as per discussion
ACTION:
- James P to run his new schematron rule over all the DGU records to see if it does impact on any of them
- Move issue to "To Implement" board
2020-13 Text for guidance on use of service metadata elements (from Sean, April 2020)#3
- Sean worked through all the issues he could find- these need converting into separate issues. This issue can then be closed.
ACTION:
- Jo to convert
2020-25 Conformity specification date (INSPIRE Validator; Peter) #12
ACTION:
- Peter to review
- This is a recommendation that should be strengthened after more recent best practice guidance, though it can't be validated.
- The encoding examples and guidance need updating
ACTION:
- Jo to ensure Colm has edit access
- Jo to fix existing table formatting issue (fixed locally but looks different in live and dev!)
- Colm to update guidance
Request to register an additional GEMINI profile #30
- The actual request (to register the Ordnance Survey metadata profile) is no longer needed, but some guidance on extensions to Gemini should be provided since it has been included in the UK Geospatial Data Standards Register
- Some guidance text could probably be added to https://agiorguk.github.io/gemini/1037-uk-gemini-standard-and-inspire-implementing-rules.html or to https://www.agi.org.uk/uk-gemini/
ACTION:
- Jo to close this issue and create one that's more fitting
- Colm to come up with draft text
General:
- Jo to make today's meeting a monthly recurring meeting
- Jo to write up these meeting notes
Present: Jo Cook, Peter Parslow, Colm Walsh, James Reid, Edd Lewis, Simon Roberts
Apologies: James Passmore
First:
- Jo showed the work she'd done in her own GitHub repositories to show that we can have two separate flow lines for "dev" and "live". This would allow us to trial fixes/changes and then set them live when the group agrees
- We agreed that this approach is great
ACTION: Jo to migrate it across to two repositories within the agiorguk GitHub
- We can then work a bit more on styling to make it acceptable to AGI Council
- In parallel, we will check each of the migrated pages to ensure the content is the same as the currently published content
ACTION: Jo to create issues/tasks/GitHub project to manage this checking
ACTION: Once created, all members to check some pages!
Second: Peter handed over the leadership of the group to Jo.
Present: Jo Cook, Peter Parslow, Colm Walsh, James Reid, Edd Lewis tried a few times to join but had technical issues
Apologies: Simon Roberts
- Jo showed what she has done to migrate the GEMINI content to https://agiorguk.github.io/gemini/.
- Jo (& Peter) will have another look at styling it more like AGI. (Thanks to James P for his suggestions)
- Jo will draft a process to document the balance of openness and control that we need
- Peter mentioned that he has 'handed in his notice' to AGI for the role of WG lead
Present: Peter Parslow, Jo Cook (archaeogeek), James Reid, James Passmore (nmtoken), Colm Walsh (coalsh)
Jo presented what she has achieved using AsciiDoctor (rather than Metanorma), viewable at https://github.com/archaeogeek/gemini. This ticks various boxes for us:
- include files allow common management of common text, at any level
- attributes also support some of the commonality
- .adoc files are fairly easy to understand, so a wider group of members will be able to process changes in comparison to the current large XML document
- fragmenting the elements into separate .adoc files looks useful
- even the Docker / AsciiDoctor GitHub action is a more widely understood technology than the XSLT & send HTML to AGI approach
We agree to complete the technical switch using the currently published content, and then make changes equivalent to the 'pending' changes already processed into HTML files sent to AGI. We expect AGI to create redirects for each of the pages from their current addresses to addresses on GitHub "pages".
Jo will continue to work on the CSS styling (Peter available to help) aiming to get colours & fonts consistent (even though they aren't at the moment!) and acceptable to AGI Council. She will then ask them what else (of the current page layout) they would like us to duplicate/impersonate.
Jo will have a think about how to manage releases; we agreed that some changes need to be batched into releases, whilst others can be immediate. We therefore need some mechanism to achieve this.
We'll meet again when the styling is presentable to Council and to discuss any changes we'll need to make to our workflow.
Present: Peter Parslow, James Reid, Jo Cook, Sean Gaffney
Jo reported that getting started with Metanorma is pretty straight forward (Docker image). Loading simple HTML files - after converting them to ASCII Doc - was straight forward (tried two tools). You can then apply "flavours" (e.g. ISO style standard, OGC style standard) - those worked well. We'd need to create our own "AGI flavour" (either using YAML or Ruby) - YAML took a lot of effort to get any result, and hit a Ruby error (which she thinks can be avoided/fixed). So she thinks it should be reasonably OK to make it "look AGI like". When we have a Docker image with our flavour, we could hook it up to a GitHub action.
We could handle our common content (service / dataset) in a "pre-Metanorma" step processing something to generate the three ASCII doc files.
Peter will investigate ASCII Doc "include files"? or transforming from our XML content?
Jo will continue (after late November), and share what she has achieved then.
Present: Peter Parslow, Jo Cook, Sean Gaffney Apologies: James Reid
Agenda:
Main aim: decide how to manage / publish the GEMINI content / pages using GitHub.
Other item: possibility of a "UK Standards Meet-up/Webinar"? (Jo)
Notes Jo happy to put a bit of time in to translating current pages to work as input to Metanorma, in order to discover how we can handle the common content & any other complexities. Metanorma would have the advantage of enabling production of a PDF version of (some of) GEMINI.
Next meeting: 12th November
Present: Peter Parslow, Sean Gaffney, James Reid, Edd Lewis, James Passmore, Apologies: Jo Cook (leave)
Metanorma: needs a style template set up first, which is often contracted to the organisation (but is documented). We don't know if it supports our 'common content'/styling requirement.
GitHub Pages (Jekyll static pages):
Write in ASCII Doc leaves options for publishing using Metanorma or others. Internally, Metanorma uses XML, but it can take ASCII Doc (& others) as input.
Should consider:
- one off skills/work to get from where we are to where we want to be
- the skills required to then maintain the document, however marked up
- the tool for publishing from that
We discussed the pros & cons of maintaining the content in AsciiDoc or HTML, but still don't consider we are equipped to make a call. James P urged us to remember that so long as the change from the current system is lossless, the choice of approach is not a 'for ever' decision.
WG members to look at https://github.com/agiorguk/gemini/blob/main/resources/Readme.md
Sean encouraged us to look at his two issues, at least to advise MEDIN: #68 and #69
Present: Peter Parslow, Sean Gaffney, James Reid. Then James Passmore after we'd finished. Apologies: Jo Cook, Edd Lewis
Edd reports: "Metanorma does work quite nicely & I personally like the idea of using common tooling with OGC/ISO
I haven’t yet managed to get it to deploy to GitHub Pages automatically"
Brief discussion:
- the fact that we'd like to get back to actually improving GEMINI! We don't really feel that deciding/selecting a publication process is "our job"
- possible pros & cons of Metanorma and 'native HTML' publication
- the list of GEMINI pages at https://github.com/agiorguk/gemini/blob/main/resources/Readme.md
- we need to push for agreement of a quorum: perhaps four? But we haven't had four people at a meeting since late July.
- Peter will close https://doodle.com/poll/vb6wq3ckxtpip7g8 this afternoon; Sean now can't make 7th October; James would prefer not the afternoon of 7th
Present: Peter Parslow, Simon Roberts (briefly), Edd Lewis Apologies: Jo Cook, Sean Gaffney, Simon Roberts
Brief discussion on Peter's contribution to https://github.com/agiorguk/gemini/issues/64. We need to get more members to interact there and/or attend.
Present: Peter Parslow, Simon Roberts, Edd Lewis Apologies: Jo Cook
DELETE 1. update on AGI Council & amending content on the website (Jo) 2. how to manage the content on GitHub (Edd)
Following an approach that OGC use to publish standards from GitHub, he has the static pages converted to Markdown from which he can generate very plain HTML - with no styling. Needs some more work on 'build' from Markdown to styles.
Perhaps more importantly, how to produce two pages with a lot of common content? "Docsy" should support this. There are other possible systems. We believe Jo has experience too.
Peter to ask Gobe what OGC use.
Some discussion of issues: #3 Sean to continue and to group the changes into 'easy' and 'requires discussion' #12 further work required to make it actually user friendly - a new action on Peter #29 need others to confirm whether it is actually non-breaking #30 some further thought will be needed
Present: Peter Parslow, Sean Gaffney, Simon Roberts, Jo Cook Apologies: Edd Lewis
Introducing Simon Roberts of Improvement Service (Scottish local authorities)
Jo reported that AGI Council support the idea of moving some or all of the GEMINI pages to GitHub (for management & publication). AGI Council require a written description of our control/publication process. They don't need an exact match of style, but want it recognisably AGI. The GEMINI pages are among the most visited pages of the AGI site. Suggestion: move the "element" pages.
Simplest: pages exist as markdown, in a "documentation" branch in the repository - commit to a "published" branch. We need to agree how to handle the code changes. But this doesn't handle the shared content bit across dataset/service/summary pages.
A bit more complex: use "read the docs" - Jo think this can handle common text blocks. May be more tricky
To do: work through the page hierarchy (web) and decide which ones move. Action: Peter to upload the 'web' picture & initiate discussion. Action: Jo put up a starter document on our change / publish process
Issue #12: Peter to tweak diagram; Jo to suggest words. Issue #29: some discussion & progress
Scotland has a well used planning data system, called "uniform" from IDOX. It would be good to get them involved / aware. Simon will sow seeds on data standards as requirements in the planning system.
Present: Peter Parslow, Sean Gaffney, Jo Cook Apologies: James Reid, Edd Lewis
Agreed to rename the project's "For closure" column to clarify the role it plays in comparison to GitHub "closed" status.
BlueStar, AGI's web support team, have requested payment for changes; AGI Council will be discussing this on Tuesday 20th, as part of a wider concern that their current contract does not support sufficient flexibility of the website. After that we will know more. One possibility would be to host GEMINI content off site (e.g. on GitHub), but it is part of a wider question. Raise an issue for this - the overall management of GEMINI pages - to provide a space to track the conversation.
issue #25: close, open a new issue on the use cases of ISO 19139 metadata for e.g. feature instances (& the questions of multiple hierarchyLevels in one file).
issue #12: we feel the diagram is incomplete. Peter to propose a fuller one
issue #28: we agreed changes to a number of things that are wrong with the description of this element (Domain, Guidance, Comments, description of encoding example). Move to "To implement".
Present: Peter Parslow, James Reid, James Passmore, Apologies: Jo Cook, John Tate
Peter explained the use he'd made of the "For closure" column (sent to AGI, waiting for them to publish) and the new "bundle" tag (i.e. where the fix should be bundled into a release, e.g. because it would require software change. We agreed to rename this to "release", and introduce a "immediate" tag for issues that can be implemented immediately.
We reviewed the discussion & agreed the implementation for #18, #19, #28, #57, #60, all of which can be implemented for immediate release.
We discussed #3 and consider it can be closed with no change; action Sean (as initiator) to confirm (or say why not)
We discussed #12 and actioned James to draft a flow chart & Peter to ask how that could be emebedded.
We discussed #16 inconclusively.
Peter to book fortnightly meetings at this time (3pm Thursdays).
Present: Peter Parslow, Sean Gaffney, Jo Cook, James Reid, Edd Lewis Apologies:
- issues pending closure - two closed issues were removed from the project
- issues pending release #31 proposed new page: not consistent between "UK GEMINI" and "GEMINI". Should
- issues for review: #25 - Jo to look, and Sean to look at MEDIN Schematron (for interest) Others resolved & moved to "to implement"
Note we have 1 in "for review", 6 in "to implement" (one of which should wait for a bundled release), 2 in "pending release", awaiting the next five.
Further discussion on #27
Present: Peter Parslow, James Reid, Edd Lewis Apologies: Sean Gaffney, Jo Cook, James Passmore
- we confirmed the changes for three issues, meaning that Peter has two HTML & one 'tracked changes' document to send to AGI's web team. These are in the "Pending release" column of the project. Note: this will result in the GEMINI 2.3 version date moving to 'now', and relevant entries shall be made in the change log.
- we agreed to close two issues with no change (there are for now in the "For closure" column of the project)
- we agreed solutions to two other issues, which are now in the "to implement" column. Peter to make the changes & release them with the others
- we briefly discussed one other, but could not proceed (assigned now to Jo)
- we discussed another and moved it back from "for review" to "under discussion".
- we'll meet again next week. Peter to book, from the preferences on the Doodle poll
Present: Peter Parslow, Sean Gaffney, James Reid, Jo Cook, James Passmore, Edd Lewis
Apologies: Rob Walker
This was our first meeting using the GitHub repository to drive the agenda. Peter introduced the columns in the project board, which have cards to describe what they are for. We agreed that not all resolved issues need to wait for a release, and that https://github.com/agiorguk/gemini/issues/9 is a good example (so Peter was right to publish it & close the issue).
- We will use meetings to agree resolutions that appear to have emerged in comments; these issues will be in the "For review" column.
- We will use meetings to agree that an implementation does in fact close an issue; at that point, a closed issue will be removed from the project.
- Our process & policy will emerge over the next few months through working on some issues. We will document discussion on versioning & release rules at https://github.com/agiorguk/gemini/issues/27 and create a document from it at some time.
- we agreed that it had been right to resolve, publish, and close one issue; we agreed the solution to two others; discussed one other (without agreeing the solution), and raised a new one.
- we should be able to create a change log for a release (or perhaps even between releases?) automatically from GitHub; needs some investigation
- our rule for deciding when to release will emerge from experience
- @Peter to issue a Doodle poll for a next meeting in the first few days of June
Present: Peter Parslow, Sean Gaffney, James Reid, Jo Cook, Rob Walker
We looked at the two repositories and discussed our way of working. We will try to work in GitHub and have (roughly) monthly meetings to actually decide whether a 'solution' is the solution. That is, between meetings, we can put an issue in the status "for review", but only set it "agreed" at a meeting.
"Agreed" means that we know what we want to change, but someone has to go & do it. At that point, we'll assign the issue to someone to implement the change - offline, pending release.
Next meeting: 3pm (BST) 18th May
Action: Peter to reverse the "Non-breaking" label, i.e. remove it & add a "Breaking" label to the others Action: Peter to document what the labels mean (in the Readme) Action: Peter to create status ("can ban") columns, and assign the open actions to them. Probable statuses: new, in progress, for review, agreed