[GitHub] [jena] adibaba opened a new pull request #647: Added dcat:Resource
adibaba opened a new pull request #647: Added dcat:Resource URL: https://github.com/apache/jena/pull/647 Double-checked DCAT2 changes with https://w3c.github.io/dxwg/dcat/rdf/dcat.ttl dcat:Resource is the only missing URI in namespace. Code: https://github.com/projekt-opal/vocabulary-enhancement/blob/197a19ab369420a6b43961738a5dbe3140417e0b/src/main/java/org/dice_research/opal/vocabulary_enhancement/RdfImporter.java#L26 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: changes to Apache Jena site documentation
looks good On Fri, Dec 6, 2019 at 9:28 PM Andy Seaborne wrote: > > > On 06/12/2019 13:38, Marco Neumann wrote: > > Thanks Adam, > > > > the process sounds a bit cumbersome, but in any event the page I have > > already edited is here > > > > > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > > > > the idea was to update the bread crumb navigation items since currently > to > > spatial search links to a 404 > > It is in templates/skeleton.html and I've changed Spatial Search to > GeoSPARQL > > FYI: I've found in the past that Apache site is quite aggressive on > caching so you may need to do a hard refresh > > Andy > -- --- Marco Neumann KONA
Re: changes to Apache Jena site documentation
On 06/12/2019 13:38, Marco Neumann wrote: Thanks Adam, the process sounds a bit cumbersome, but in any event the page I have already edited is here https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext the idea was to update the bread crumb navigation items since currently to spatial search links to a 404 It is in templates/skeleton.html and I've changed Spatial Search to GeoSPARQL FYI: I've found in the past that Apache site is quite aggressive on caching so you may need to do a hard refresh Andy
Re: changes to Apache Jena site documentation
thank you Adam, this will do for now On Fri, Dec 6, 2019 at 5:05 PM ajs6f wrote: > Maybe the confusion here is between "committee" (as in PMC) and > "committers", who are so-called because they have commit rights to the code > (normally earned by being personally committed to the project). Here is > some documentation about what an Apache PMC is and does as opposed to > committer-ship: > > https://apache.org/foundation/how-it-works.html#roles > > and all of https://apache.org/foundation/how-it-works.html is pretty > useful. > > https://www.apache.org/foundation/governance/pmcs > > is about PMCs specifically and: > > https://www.apache.org/foundation/governance/pmcs#merit > > is particularly relevant. > > ajs6f > > > On Dec 6, 2019, at 11:53 AM, Marco Neumann > wrote: > > > > OK I see, I have inferred that from the Apache site [1] where it says > that > > the Apache Jena Committee is also called PMC . > > > > I have seen a number of changes over the years, even predating the move > to > > Apache, so yes migrating to a new system might be an option. possibly a > > wiki type system. But it's not urgent from my point of view at the > moment. > > > > Thanks for the explanation attempt. > > > > [1] https://projects.apache.org/committee.html?jena > > > > > > > > > > > > > > On Fri, Dec 6, 2019 at 4:31 PM ajs6f wrote: > > > >> No, I didn't mention the PMC at all. > >> > >> Perhaps we're getting confused here because like other Apache projects, > >> Jena has both a roster of committers, who have privileges to work on the > >> codebase and docbase, but also a Project Management Committee or PMC (of > >> which Andy is now the chair), which is ultimately responsible for the > >> conduct of the Jena project to the Apache Foundation. The PMC, amongst a > >> few other duties, elects new committers. Like many Apache projects, > those > >> lists for Jena are substantially the same (with a few small > differences), > >> but the only one that is relevant here is the committer roster. > >> > >> As for other kinds of roles, I'm not sure how much flexibility is > >> available from the Apache bylaws, but I know of no other project that > >> features other "official" roles-- that is, roles other than committer or > >> PMC member that would be recognized by the Foundation. We've discussed > >> this question before and come to the conclusion that the Jena project is > >> small enough that we don't need any new roles-- that if someone is > making > >> contributions that should be recognized with a greater level of > >> responsibility (whether or not those contributions are in the form of > code > >> or something else like work answering questions on the mailing lists, > >> etc.), we can simply make them a committer immediately. > >> > >> Does that help explain? > >> > >> In any event, several threads over the past months (years now, I think!) > >> have arisen on this list to the effect that our documentation in Apache > >> INFRA's old-line CMS isn't easy to maintain or publish, so that > >> alternatives are attractive. I suspect that real improvement for our > >> documentation process would be better achieved by migrating to a new > system. > >> > >> ajs6f > >> > >>> On Dec 6, 2019, at 11:17 AM, Marco Neumann > >> wrote: > >>> > >>> in short yes, I would think for documentation purposes and the like a > >> more > >>> relaxed form of participation should be available. So you say currently > >>> only members with role PMC can commit edits to the documentation on the > >>> apache cms? Can roles be dynamically generated here or does each Apache > >>> project has only one type of role membership on the Apache cms? > >>> > >>> > >>> > >>> On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: > >>> > It is not tied into that build process, except for the Javadocs, since > Javadocs are extracted from the codebase. There is no need to build > the > codebase to publish the site as a whole. > > As for assigning an account to individual users, I'm not quite sure > what > that would do. Currently accounts are for committers because only > committers can make changes to the documentation. Are you suggesting > >> that > we allow any user with an account to make changes there and allow any > >> Jena > user who asks to have an account? Or something else? > > ajs6f > > > On Dec 6, 2019, at 10:52 AM, Marco Neumann > wrote: > > > > assign user name and password to individual users? I'd say it doesn't > need > > to be tied into the build process of the Apache Jena project IIUC > > > > On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > > > >> Did you have suggestions for a different process? > >> > >> ajs6f > >> > >>> On Dec 6, 2019, at 8:38 AM, Marco Neumann > > >> wrote: > >>> > >>> Thanks Adam, > >>> > >>> the process sounds a bit cumbersome, but in any event the page I > have > >>> already edited is here > >>>
Re: changes to Apache Jena site documentation
Maybe the confusion here is between "committee" (as in PMC) and "committers", who are so-called because they have commit rights to the code (normally earned by being personally committed to the project). Here is some documentation about what an Apache PMC is and does as opposed to committer-ship: https://apache.org/foundation/how-it-works.html#roles and all of https://apache.org/foundation/how-it-works.html is pretty useful. https://www.apache.org/foundation/governance/pmcs is about PMCs specifically and: https://www.apache.org/foundation/governance/pmcs#merit is particularly relevant. ajs6f > On Dec 6, 2019, at 11:53 AM, Marco Neumann wrote: > > OK I see, I have inferred that from the Apache site [1] where it says that > the Apache Jena Committee is also called PMC . > > I have seen a number of changes over the years, even predating the move to > Apache, so yes migrating to a new system might be an option. possibly a > wiki type system. But it's not urgent from my point of view at the moment. > > Thanks for the explanation attempt. > > [1] https://projects.apache.org/committee.html?jena > > > > > > > On Fri, Dec 6, 2019 at 4:31 PM ajs6f wrote: > >> No, I didn't mention the PMC at all. >> >> Perhaps we're getting confused here because like other Apache projects, >> Jena has both a roster of committers, who have privileges to work on the >> codebase and docbase, but also a Project Management Committee or PMC (of >> which Andy is now the chair), which is ultimately responsible for the >> conduct of the Jena project to the Apache Foundation. The PMC, amongst a >> few other duties, elects new committers. Like many Apache projects, those >> lists for Jena are substantially the same (with a few small differences), >> but the only one that is relevant here is the committer roster. >> >> As for other kinds of roles, I'm not sure how much flexibility is >> available from the Apache bylaws, but I know of no other project that >> features other "official" roles-- that is, roles other than committer or >> PMC member that would be recognized by the Foundation. We've discussed >> this question before and come to the conclusion that the Jena project is >> small enough that we don't need any new roles-- that if someone is making >> contributions that should be recognized with a greater level of >> responsibility (whether or not those contributions are in the form of code >> or something else like work answering questions on the mailing lists, >> etc.), we can simply make them a committer immediately. >> >> Does that help explain? >> >> In any event, several threads over the past months (years now, I think!) >> have arisen on this list to the effect that our documentation in Apache >> INFRA's old-line CMS isn't easy to maintain or publish, so that >> alternatives are attractive. I suspect that real improvement for our >> documentation process would be better achieved by migrating to a new system. >> >> ajs6f >> >>> On Dec 6, 2019, at 11:17 AM, Marco Neumann >> wrote: >>> >>> in short yes, I would think for documentation purposes and the like a >> more >>> relaxed form of participation should be available. So you say currently >>> only members with role PMC can commit edits to the documentation on the >>> apache cms? Can roles be dynamically generated here or does each Apache >>> project has only one type of role membership on the Apache cms? >>> >>> >>> >>> On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: >>> It is not tied into that build process, except for the Javadocs, since Javadocs are extracted from the codebase. There is no need to build the codebase to publish the site as a whole. As for assigning an account to individual users, I'm not quite sure what that would do. Currently accounts are for committers because only committers can make changes to the documentation. Are you suggesting >> that we allow any user with an account to make changes there and allow any >> Jena user who asks to have an account? Or something else? ajs6f > On Dec 6, 2019, at 10:52 AM, Marco Neumann wrote: > > assign user name and password to individual users? I'd say it doesn't need > to be tied into the build process of the Apache Jena project IIUC > > On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > >> Did you have suggestions for a different process? >> >> ajs6f >> >>> On Dec 6, 2019, at 8:38 AM, Marco Neumann >> wrote: >>> >>> Thanks Adam, >>> >>> the process sounds a bit cumbersome, but in any event the page I have >>> already edited is here >>> >>> >> >> https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext >>> >>> >>> the idea was to update the bread crumb navigation items since >> currently >> to >>> spatial search links to a 404 >>> >>> >>>
Re: changes to Apache Jena site documentation
OK I see, I have inferred that from the Apache site [1] where it says that the Apache Jena Committee is also called PMC . I have seen a number of changes over the years, even predating the move to Apache, so yes migrating to a new system might be an option. possibly a wiki type system. But it's not urgent from my point of view at the moment. Thanks for the explanation attempt. [1] https://projects.apache.org/committee.html?jena On Fri, Dec 6, 2019 at 4:31 PM ajs6f wrote: > No, I didn't mention the PMC at all. > > Perhaps we're getting confused here because like other Apache projects, > Jena has both a roster of committers, who have privileges to work on the > codebase and docbase, but also a Project Management Committee or PMC (of > which Andy is now the chair), which is ultimately responsible for the > conduct of the Jena project to the Apache Foundation. The PMC, amongst a > few other duties, elects new committers. Like many Apache projects, those > lists for Jena are substantially the same (with a few small differences), > but the only one that is relevant here is the committer roster. > > As for other kinds of roles, I'm not sure how much flexibility is > available from the Apache bylaws, but I know of no other project that > features other "official" roles-- that is, roles other than committer or > PMC member that would be recognized by the Foundation. We've discussed > this question before and come to the conclusion that the Jena project is > small enough that we don't need any new roles-- that if someone is making > contributions that should be recognized with a greater level of > responsibility (whether or not those contributions are in the form of code > or something else like work answering questions on the mailing lists, > etc.), we can simply make them a committer immediately. > > Does that help explain? > > In any event, several threads over the past months (years now, I think!) > have arisen on this list to the effect that our documentation in Apache > INFRA's old-line CMS isn't easy to maintain or publish, so that > alternatives are attractive. I suspect that real improvement for our > documentation process would be better achieved by migrating to a new system. > > ajs6f > > > On Dec 6, 2019, at 11:17 AM, Marco Neumann > wrote: > > > > in short yes, I would think for documentation purposes and the like a > more > > relaxed form of participation should be available. So you say currently > > only members with role PMC can commit edits to the documentation on the > > apache cms? Can roles be dynamically generated here or does each Apache > > project has only one type of role membership on the Apache cms? > > > > > > > > On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: > > > >> It is not tied into that build process, except for the Javadocs, since > >> Javadocs are extracted from the codebase. There is no need to build the > >> codebase to publish the site as a whole. > >> > >> As for assigning an account to individual users, I'm not quite sure what > >> that would do. Currently accounts are for committers because only > >> committers can make changes to the documentation. Are you suggesting > that > >> we allow any user with an account to make changes there and allow any > Jena > >> user who asks to have an account? Or something else? > >> > >> ajs6f > >> > >>> On Dec 6, 2019, at 10:52 AM, Marco Neumann > >> wrote: > >>> > >>> assign user name and password to individual users? I'd say it doesn't > >> need > >>> to be tied into the build process of the Apache Jena project IIUC > >>> > >>> On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > >>> > Did you have suggestions for a different process? > > ajs6f > > > On Dec 6, 2019, at 8:38 AM, Marco Neumann > wrote: > > > > Thanks Adam, > > > > the process sounds a bit cumbersome, but in any event the page I have > > already edited is here > > > > > > >> > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > > > > the idea was to update the bread crumb navigation items since > currently > to > > spatial search links to a 404 > > > > > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > > > >> Yes, a committer needs to push the change through to be committed to > >> the > >> documentation base, and then the site must be published. We always > publish > >> for a release, but we can publish at other times, too, if needed. > >> > >> I do not recall seeing the actual change come across dev@ (which it > >> normally would). Do you have a link to the patch in the Apache CMS > handy? I > >> am happy to review and commit it. > >> > >> ajs6f > >> > >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann > > >> wrote: > >>> > >>> I have made some changes to the documentation on the > jena.apache.org > >> site > >>> with the anonymous
Re: changes to Apache Jena site documentation
No, I didn't mention the PMC at all. Perhaps we're getting confused here because like other Apache projects, Jena has both a roster of committers, who have privileges to work on the codebase and docbase, but also a Project Management Committee or PMC (of which Andy is now the chair), which is ultimately responsible for the conduct of the Jena project to the Apache Foundation. The PMC, amongst a few other duties, elects new committers. Like many Apache projects, those lists for Jena are substantially the same (with a few small differences), but the only one that is relevant here is the committer roster. As for other kinds of roles, I'm not sure how much flexibility is available from the Apache bylaws, but I know of no other project that features other "official" roles-- that is, roles other than committer or PMC member that would be recognized by the Foundation. We've discussed this question before and come to the conclusion that the Jena project is small enough that we don't need any new roles-- that if someone is making contributions that should be recognized with a greater level of responsibility (whether or not those contributions are in the form of code or something else like work answering questions on the mailing lists, etc.), we can simply make them a committer immediately. Does that help explain? In any event, several threads over the past months (years now, I think!) have arisen on this list to the effect that our documentation in Apache INFRA's old-line CMS isn't easy to maintain or publish, so that alternatives are attractive. I suspect that real improvement for our documentation process would be better achieved by migrating to a new system. ajs6f > On Dec 6, 2019, at 11:17 AM, Marco Neumann wrote: > > in short yes, I would think for documentation purposes and the like a more > relaxed form of participation should be available. So you say currently > only members with role PMC can commit edits to the documentation on the > apache cms? Can roles be dynamically generated here or does each Apache > project has only one type of role membership on the Apache cms? > > > > On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: > >> It is not tied into that build process, except for the Javadocs, since >> Javadocs are extracted from the codebase. There is no need to build the >> codebase to publish the site as a whole. >> >> As for assigning an account to individual users, I'm not quite sure what >> that would do. Currently accounts are for committers because only >> committers can make changes to the documentation. Are you suggesting that >> we allow any user with an account to make changes there and allow any Jena >> user who asks to have an account? Or something else? >> >> ajs6f >> >>> On Dec 6, 2019, at 10:52 AM, Marco Neumann >> wrote: >>> >>> assign user name and password to individual users? I'd say it doesn't >> need >>> to be tied into the build process of the Apache Jena project IIUC >>> >>> On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: >>> Did you have suggestions for a different process? ajs6f > On Dec 6, 2019, at 8:38 AM, Marco Neumann wrote: > > Thanks Adam, > > the process sounds a bit cumbersome, but in any event the page I have > already edited is here > > >> https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > the idea was to update the bread crumb navigation items since currently to > spatial search links to a 404 > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > >> Yes, a committer needs to push the change through to be committed to >> the >> documentation base, and then the site must be published. We always publish >> for a release, but we can publish at other times, too, if needed. >> >> I do not recall seeing the actual change come across dev@ (which it >> normally would). Do you have a link to the patch in the Apache CMS handy? I >> am happy to review and commit it. >> >> ajs6f >> >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann >> wrote: >>> >>> I have made some changes to the documentation on the jena.apache.org >> site >>> with the anonymous username and can indeed see these changes now in >> the >>> edit view but not in the live view. Is this correct behavior, does >> this >>> change wait for some admin approval? >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
in short yes, I would think for documentation purposes and the like a more relaxed form of participation should be available. So you say currently only members with role PMC can commit edits to the documentation on the apache cms? Can roles be dynamically generated here or does each Apache project has only one type of role membership on the Apache cms? On Fri, Dec 6, 2019 at 3:58 PM ajs6f wrote: > It is not tied into that build process, except for the Javadocs, since > Javadocs are extracted from the codebase. There is no need to build the > codebase to publish the site as a whole. > > As for assigning an account to individual users, I'm not quite sure what > that would do. Currently accounts are for committers because only > committers can make changes to the documentation. Are you suggesting that > we allow any user with an account to make changes there and allow any Jena > user who asks to have an account? Or something else? > > ajs6f > > > On Dec 6, 2019, at 10:52 AM, Marco Neumann > wrote: > > > > assign user name and password to individual users? I'd say it doesn't > need > > to be tied into the build process of the Apache Jena project IIUC > > > > On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > > > >> Did you have suggestions for a different process? > >> > >> ajs6f > >> > >>> On Dec 6, 2019, at 8:38 AM, Marco Neumann > >> wrote: > >>> > >>> Thanks Adam, > >>> > >>> the process sounds a bit cumbersome, but in any event the page I have > >>> already edited is here > >>> > >>> > >> > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > >>> > >>> > >>> the idea was to update the bread crumb navigation items since currently > >> to > >>> spatial search links to a 404 > >>> > >>> > >>> > >>> On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > >>> > Yes, a committer needs to push the change through to be committed to > the > documentation base, and then the site must be published. We always > >> publish > for a release, but we can publish at other times, too, if needed. > > I do not recall seeing the actual change come across dev@ (which it > normally would). Do you have a link to the patch in the Apache CMS > >> handy? I > am happy to review and commit it. > > ajs6f > > > On Dec 4, 2019, at 2:58 PM, Marco Neumann > wrote: > > > > I have made some changes to the documentation on the jena.apache.org > site > > with the anonymous username and can indeed see these changes now in > the > > edit view but not in the live view. Is this correct behavior, does > this > > change wait for some admin approval? > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > > >>> > >>> -- > >>> > >>> > >>> --- > >>> Marco Neumann > >>> KONA > >> > >> > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > -- --- Marco Neumann KONA
Re: changes to Apache Jena site documentation
It is not tied into that build process, except for the Javadocs, since Javadocs are extracted from the codebase. There is no need to build the codebase to publish the site as a whole. As for assigning an account to individual users, I'm not quite sure what that would do. Currently accounts are for committers because only committers can make changes to the documentation. Are you suggesting that we allow any user with an account to make changes there and allow any Jena user who asks to have an account? Or something else? ajs6f > On Dec 6, 2019, at 10:52 AM, Marco Neumann wrote: > > assign user name and password to individual users? I'd say it doesn't need > to be tied into the build process of the Apache Jena project IIUC > > On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > >> Did you have suggestions for a different process? >> >> ajs6f >> >>> On Dec 6, 2019, at 8:38 AM, Marco Neumann >> wrote: >>> >>> Thanks Adam, >>> >>> the process sounds a bit cumbersome, but in any event the page I have >>> already edited is here >>> >>> >> https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext >>> >>> >>> the idea was to update the bread crumb navigation items since currently >> to >>> spatial search links to a 404 >>> >>> >>> >>> On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: >>> Yes, a committer needs to push the change through to be committed to the documentation base, and then the site must be published. We always >> publish for a release, but we can publish at other times, too, if needed. I do not recall seeing the actual change come across dev@ (which it normally would). Do you have a link to the patch in the Apache CMS >> handy? I am happy to review and commit it. ajs6f > On Dec 4, 2019, at 2:58 PM, Marco Neumann wrote: > > I have made some changes to the documentation on the jena.apache.org site > with the anonymous username and can indeed see these changes now in the > edit view but not in the live view. Is this correct behavior, does this > change wait for some admin approval? > > -- > > > --- > Marco Neumann > KONA >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
if use anonymous as username you should be able to see the changed structure. basically if you currently access the public site and you select Spatial Search in the Javadoc drop-down it will lead you to a Not Found 404. I suggest to replace the item with a link to the GeoSPARQL documentation as outlined in the change. On Fri, Dec 6, 2019 at 3:40 PM Andy Seaborne wrote: > I can't access the link - that can be because it wasn't committed, or it > thinks I'm editing something. > > Marco - could you put it on a gist and email the link? > > because it is under "javadoc/" it needs special handling as a script > resets tha whole of "javadoc/" as part of the release process. > > Andy > > On 06/12/2019 13:38, Marco Neumann wrote: > > Thanks Adam, > > > > the process sounds a bit cumbersome, but in any event the page I have > > already edited is here > > > > > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > > > > the idea was to update the bread crumb navigation items since currently > to > > spatial search links to a 404 > > > > > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > > > >> Yes, a committer needs to push the change through to be committed to the > >> documentation base, and then the site must be published. We always > publish > >> for a release, but we can publish at other times, too, if needed. > >> > >> I do not recall seeing the actual change come across dev@ (which it > >> normally would). Do you have a link to the patch in the Apache CMS > handy? I > >> am happy to review and commit it. > >> > >> ajs6f > >> > >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann > >> wrote: > >>> > >>> I have made some changes to the documentation on the jena.apache.org > >> site > >>> with the anonymous username and can indeed see these changes now in the > >>> edit view but not in the live view. Is this correct behavior, does this > >>> change wait for some admin approval? > >>> > >>> -- > >>> > >>> > >>> --- > >>> Marco Neumann > >>> KONA > >> > >> > > > -- --- Marco Neumann KONA
Re: changes to Apache Jena site documentation
assign user name and password to individual users? I'd say it doesn't need to be tied into the build process of the Apache Jena project IIUC On Fri, Dec 6, 2019 at 3:41 PM ajs6f wrote: > Did you have suggestions for a different process? > > ajs6f > > > On Dec 6, 2019, at 8:38 AM, Marco Neumann > wrote: > > > > Thanks Adam, > > > > the process sounds a bit cumbersome, but in any event the page I have > > already edited is here > > > > > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > > > > the idea was to update the bread crumb navigation items since currently > to > > spatial search links to a 404 > > > > > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > > > >> Yes, a committer needs to push the change through to be committed to the > >> documentation base, and then the site must be published. We always > publish > >> for a release, but we can publish at other times, too, if needed. > >> > >> I do not recall seeing the actual change come across dev@ (which it > >> normally would). Do you have a link to the patch in the Apache CMS > handy? I > >> am happy to review and commit it. > >> > >> ajs6f > >> > >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann > >> wrote: > >>> > >>> I have made some changes to the documentation on the jena.apache.org > >> site > >>> with the anonymous username and can indeed see these changes now in the > >>> edit view but not in the live view. Is this correct behavior, does this > >>> change wait for some admin approval? > >>> > >>> -- > >>> > >>> > >>> --- > >>> Marco Neumann > >>> KONA > >> > >> > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > -- --- Marco Neumann KONA
[jira] [Commented] (JENA-1785) A newly created node can remain invisible after commit
[ https://issues.apache.org/jira/browse/JENA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989901#comment-16989901 ] Pavel Mikhailovskii commented on JENA-1785: --- This is indeed a correct explanation of the problem. To put it short, the problem is that even though newly added nodes are removed from the local version of the not-present cache, they don't get removed from the global cache on commit. > A newly created node can remain invisible after commit > -- > > Key: JENA-1785 > URL: https://issues.apache.org/jira/browse/JENA-1785 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.13.0, Jena 3.13.1 >Reporter: Pavel Mikhailovskii >Assignee: Andy Seaborne >Priority: Critical > Attachments: TestVisibilityOfChanges.java > > Time Spent: 1h > Remaining Estimate: 0h > > A node once marked as non-present (_NodeTableCache.nonPresent_) can remain > invisible even after it's created and the transaction is committed. That > might happen because there's no guarantee that *all* newly created nodes will > be eventually added to the "base" version _ThreadBufferingCache.baseCache_ of > the _node2id_Cache_ (as the _localCache_ has limited capacity) or removed > from the "base" version of the _nonPresent_ cache (even if they were, there > would still be a chance of re-adding them by some read transaction). > The simplest fix is to get rid of the _nonPresent_ cache which seems to be of > limited use anyway. A more sophisticated fix would involve keeping track of > all newly allocated nodes and their removal from the base version of > _nonPresent_ cache on transaction commit. > To reproduce: see the attached test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: changes to Apache Jena site documentation
Did you have suggestions for a different process? ajs6f > On Dec 6, 2019, at 8:38 AM, Marco Neumann wrote: > > Thanks Adam, > > the process sounds a bit cumbersome, but in any event the page I have > already edited is here > > https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext > > > the idea was to update the bread crumb navigation items since currently to > spatial search links to a 404 > > > > On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > >> Yes, a committer needs to push the change through to be committed to the >> documentation base, and then the site must be published. We always publish >> for a release, but we can publish at other times, too, if needed. >> >> I do not recall seeing the actual change come across dev@ (which it >> normally would). Do you have a link to the patch in the Apache CMS handy? I >> am happy to review and commit it. >> >> ajs6f >> >>> On Dec 4, 2019, at 2:58 PM, Marco Neumann >> wrote: >>> >>> I have made some changes to the documentation on the jena.apache.org >> site >>> with the anonymous username and can indeed see these changes now in the >>> edit view but not in the live view. Is this correct behavior, does this >>> change wait for some admin approval? >>> >>> -- >>> >>> >>> --- >>> Marco Neumann >>> KONA >> >> > > -- > > > --- > Marco Neumann > KONA
Re: changes to Apache Jena site documentation
I can't access the link - that can be because it wasn't committed, or it thinks I'm editing something. Marco - could you put it on a gist and email the link? because it is under "javadoc/" it needs special handling as a script resets tha whole of "javadoc/" as part of the release process. Andy On 06/12/2019 13:38, Marco Neumann wrote: Thanks Adam, the process sounds a bit cumbersome, but in any event the page I have already edited is here https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext the idea was to update the bread crumb navigation items since currently to spatial search links to a 404 On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: Yes, a committer needs to push the change through to be committed to the documentation base, and then the site must be published. We always publish for a release, but we can publish at other times, too, if needed. I do not recall seeing the actual change come across dev@ (which it normally would). Do you have a link to the patch in the Apache CMS handy? I am happy to review and commit it. ajs6f On Dec 4, 2019, at 2:58 PM, Marco Neumann wrote: I have made some changes to the documentation on the jena.apache.org site with the anonymous username and can indeed see these changes now in the edit view but not in the live view. Is this correct behavior, does this change wait for some admin approval? -- --- Marco Neumann KONA
Re: changes to Apache Jena site documentation
Thanks Adam, the process sounds a bit cumbersome, but in any event the page I have already edited is here https://cms.apache.org/jena/wc/edit/anonymous-n3xU7Y/trunk/content/documentation/javadoc/index.mdtext the idea was to update the bread crumb navigation items since currently to spatial search links to a 404 On Thu, Dec 5, 2019 at 7:49 PM ajs6f wrote: > Yes, a committer needs to push the change through to be committed to the > documentation base, and then the site must be published. We always publish > for a release, but we can publish at other times, too, if needed. > > I do not recall seeing the actual change come across dev@ (which it > normally would). Do you have a link to the patch in the Apache CMS handy? I > am happy to review and commit it. > > ajs6f > > > On Dec 4, 2019, at 2:58 PM, Marco Neumann > wrote: > > > > I have made some changes to the documentation on the jena.apache.org > site > > with the anonymous username and can indeed see these changes now in the > > edit view but not in the live view. Is this correct behavior, does this > > change wait for some admin approval? > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > -- --- Marco Neumann KONA
[jira] [Comment Edited] (JENA-1785) A newly created node can remain invisible after commit
[ https://issues.apache.org/jira/browse/JENA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989698#comment-16989698 ] Andy Seaborne edited comment on JENA-1785 at 12/6/19 12:27 PM: --- Here is my understanding of the problem: this is mainly to make sure I understand the details here! The NodeTable Cache should reflect the node table. The NodeTable is append-only and it does not matter if nodes are added to it by later transactions; what is in the data is determined by the triples/quads, not by presence in the node table. Inside a write-transaction things are different because the W-txn may abort. Nodes created should not be visible outside the W-txn until it commits (JENA-1746). The fact nodes are cleared up from storage after an abort was the problem in JENA-1746. The underlying disk storage, a TransBinaryDataFile, reflects transactions. In a W-txn, there is the visible part (all still running read-transactions) and the additional nodes of the W-txn. NodeTableCache has buffering caches that attempts to reflect this. These are ThreadBufferingCache, which is a pair of normal LRU caches, one "local" for the W-txn nodes and one "base" for the globally visible cache of the node table. The same structure is used for the not-present cache. Problem: A node is initially recorded as "not present". It is now in the base-not-present cache. A W-txn adds this node, putting it in the node/nodeId caches as well as writing through to the TransBinaryDataFile. It is removed from the not-present-local cache if in there. The code correctly checks to this point because the node/nodeId caching is checked before not-present. However, problems arise if it falls out of the local node/nodeId cache. Now, a lookup will not find it in a local cache, but will get the wrong answer when it finds it in the base caching because it is in the base-not-present cache. was (Author: andy.seaborne): Here is my understanding of the problem: this is mainly to make sure I understand the details here! The NodeTable Cache should reflect the node table. The NodeTable is append-only and it does not matter if nodes are added to it by later transactions; what is in the data is determined by the triples/quads, not by presence in the node table. Inside a write-transaction things are different because the W-txn may abort. Nodes created should not be visible outside the W-txn until it commits (JENA-1746). The fact nodes are cleared up from storage after an abort was the problem in JENA-1746. The underlying disk storage, a TransBinaryDataFile, reflects transactions. In a W-txn, there is the visible part (all still running read-transactions) and the additional nodes of the W-txn. NodeTableCache has buffering caches that attempts to reflect this. These are ThreadBufferingCache, which is a pair of normal LRU caches, one "local" for the W-txn nodes and one "base" for the globally visible cache of the node table. The same structure is used for the not-present cache. Problem: A node is initially recorded as "not present". It is now in the base-not-present cache. A W-txn adds this node, putting it in the node<->nodeId caches as well as writing through to the TransBinaryDataFile. It is removed from the not-present-local cache if in there. The code correctly checks to this point because the node<->nodeId caching is checked before not-present. However, problems arise if it falls out of the local node/nodeId cache. Now, a lookup will not find it in a local cache, but will get the wrong answer when it finds it in the base caching because it is in the base-not-present cache. > A newly created node can remain invisible after commit > -- > > Key: JENA-1785 > URL: https://issues.apache.org/jira/browse/JENA-1785 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.13.0, Jena 3.13.1 >Reporter: Pavel Mikhailovskii >Assignee: Andy Seaborne >Priority: Critical > Attachments: TestVisibilityOfChanges.java > > Time Spent: 1h > Remaining Estimate: 0h > > A node once marked as non-present (_NodeTableCache.nonPresent_) can remain > invisible even after it's created and the transaction is committed. That > might happen because there's no guarantee that *all* newly created nodes will > be eventually added to the "base" version _ThreadBufferingCache.baseCache_ of > the _node2id_Cache_ (as the _localCache_ has limited capacity) or removed > from the "base" version of the _nonPresent_ cache (even if they were, there > would still be a chance of re-adding them by some read transaction). > The simplest fix is to get rid of the _nonPresent_ cache which seems to be of > limited use anyway. A more sophisticated fix
[jira] [Commented] (JENA-1785) A newly created node can remain invisible after commit
[ https://issues.apache.org/jira/browse/JENA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989698#comment-16989698 ] Andy Seaborne commented on JENA-1785: - Here is my understanding of the problem: this is mainly to make sure I understand the details here! The NodeTable Cache should reflect the node table. The NodeTable is append-only and it does not matter if nodes are added to it by later transactions; what is in the data is determined by the triples/quads, not by presence in the node table. Inside a write-transaction things are different because the W-txn may abort. Nodes created should not be visible outside the W-txn until it commits (JENA-1746). The fact nodes are cleared up from storage after an abort was the problem in JENA-1746. The underlying disk storage, a TransBinaryDataFile, reflects transactions. In a W-txn, there is the visible part (all still running read-transactions) and the additional nodes of the W-txn. NodeTableCache has buffering caches that attempts to reflect this. These are ThreadBufferingCache, which is a pair of normal LRU caches, one "local" for the W-txn nodes and one "base" for the globally visible cache of the node table. The same structure is used for the not-present cache. Problem: A node is initially recorded as "not present". It is now in the base-not-present cache. A W-txn adds this node, putting it in the node<->nodeId caches as well as writing through to the TransBinaryDataFile. It is removed from the not-present-local cache if in there. The code correctly checks to this point because the node<->nodeId caching is checked before not-present. However, problems arise if it falls out of the local node/nodeId cache. Now, a lookup will not find it in a local cache, but will get the wrong answer when it finds it in the base caching because it is in the base-not-present cache. > A newly created node can remain invisible after commit > -- > > Key: JENA-1785 > URL: https://issues.apache.org/jira/browse/JENA-1785 > Project: Apache Jena > Issue Type: Bug > Components: TDB2 >Affects Versions: Jena 3.13.0, Jena 3.13.1 >Reporter: Pavel Mikhailovskii >Assignee: Andy Seaborne >Priority: Critical > Attachments: TestVisibilityOfChanges.java > > Time Spent: 1h > Remaining Estimate: 0h > > A node once marked as non-present (_NodeTableCache.nonPresent_) can remain > invisible even after it's created and the transaction is committed. That > might happen because there's no guarantee that *all* newly created nodes will > be eventually added to the "base" version _ThreadBufferingCache.baseCache_ of > the _node2id_Cache_ (as the _localCache_ has limited capacity) or removed > from the "base" version of the _nonPresent_ cache (even if they were, there > would still be a chance of re-adding them by some read transaction). > The simplest fix is to get rid of the _nonPresent_ cache which seems to be of > limited use anyway. A more sophisticated fix would involve keeping track of > all newly allocated nodes and their removal from the base version of > _nonPresent_ cache on transaction commit. > To reproduce: see the attached test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
