Hi Murray,
Just a quick note, current wiki syntax allows a second | in order to
support link attributes, e.g., [Page|MyPage|title='Page']. Markdown syntax
allows the same thing using [](){}, IIRC, so perhaps
[Subject|Predicate::Object] (or something like that) could be used instead?
cheers,
juan pablo
El vie, 29 jul 2022 4:39, Murray Altheim <murra...@altheim.com> escribió:
> On 2022/07/29 6:01, Juan Pablo Santos Rodríguez wrote:
> > Hi Murray,
> >
> > ahh ok, now I see, so I guess we could start by making the reference
> > manager pluggable through a wiki property, so anyone wishing to use it
> can
> > do so easily.
>
> Hi Juan Pablo,
>
> The one pseudo-proposal I'm considering adding to the syntax would be to
> support normal intra-wiki links, but also optionally permit a second
> vertical bar character '|' to create a triple/tuple, e.g.:
>
> [Subject|Predicate|Object]
>
> so that one could type a link to a page using another page. E.g.,
>
> [ThisPage|IsPreviousToPage|ThatPage]
> [ThatPage|HasPreviousPage|ThisPage]
> [ThisPage|HasParentPage|ThatPage]
> [ThisPage|HasCategory|ThatPage]
> [ErnestHemingway|IsA|Writer]
> [TheCat|SitsOn|TheMat]
>
> I did something similar back around 2005 with a wiki plugin that did
> exactly this, but with this proposal it'd be integrated as link syntax
> rather than as a plugin.
>
> This allows you to make a relationship between two pages (or a page and an
> external URL) that is typed by another page. That predicate page could in
> theory (in my system it always is) part of a predicate hierarchy. But I
> won't lead the team down that ontological rabbit hole. But for a teaser,
> one could create the predicates for first order predicate logic and begin
> to make statements between wiki pages (as "Terms) that describe what they
> mean. [This was part of the core of my unfinished Ph.D. work at that time.]
>
> So taking Cyc's definition of its 'genls' (inheritance) predicate:
>
> (isa genls TransitiveBinaryPredicate)
> (isa genls ReflexiveBinaryPredicate)
> (arg1Isa genls Collection)
> (arg2Isa genls Collection)
> (arg1Genl genls Thing)
> (arg2Genl genls Thing)
>
> one could express that as wiki pages with only minor syntactical changes:
>
> [IsA|Genls|TransitiveBinaryPredicate]
> [IsA|Genls|ReflexiveBinaryPredicate]
> [Arg1Isa|Genls|Collection]
> [Arg2Isa|Genls|Collection]
> [Arg1Genl|Genls|Thing]
> [Arg2Genl|Genls|Thing]
>
> But like I said, I won't go any further down that rabbit hole.
>
> > Setting aside when to switch to JDK-11 (or whatever version we see fit),
> > the graphmanager could be compiled with Java 11, having the rest of the
> > project compiling with Java 8. The markdown module has been in a similar
> > situation in the past, where it has been compiling with Java 8, and the
> > rest of the project with Java 6 or 7, so that shouldn't be a stopper..
> >
> > As for the number of pages, jspwiki-wiki has almost 400 pages, but there
> > are other wikis out there with higher number of pages; f.ex.,
> > https://encyclopaedia-wot.org has almost 4000 pages,
> > https://www.ecyrd.com/ButtUgly/wiki has around 3200 and
> http://ldapwiki.com/
> > almost 16400
>
> That probably shouldn't be an issue. I've got a test corpus of around 1200
> files that I could copy a few times to do a test at the 16K level and find
> out how long things take to process. I would be interested in knowing if
> there are any stats for that 16400 page wiki I could compare with... The
> ingest/accession (import/process metadata) on 1200 files with my digital
> library software is about 40 seconds, but that's also moving and writing
> files and creating an archive file for each. I might try to create a
> benchmark unit test to see how performance rates just for the reference
> manager.
>
> I'd still rather avoid Java serialisation/deserialisation if it turns out
> the difference between that and simply reading the source files isn't that
> huge. A lot cleaner design for sure. With high-frequence and multi-core
> CPUs, VMs and SSDs a lot of things that used to take a lot of time simply
> don't. I bought a 12 core, 24 thread i9 recently and my compile times
> (when coupled with command line optimisations) went from 90-120 seconds
> down to 15. For something like the reference manager where it's all reads
> and no writes (if we avoid serialisation on shutdown), then I think the
> performance even on 16K files should be reasonable. Interesting to test in
> any case.
>
> My time comes in spurts so I'm not sure how long this will take. I've
> currently got the bones of it, the easy bits, the rest is coming along...
>
> Cheers,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ ===
> ===
> = =
> ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
>
