Page types
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Page types
by ChristopheDD
::
Rate this Message:
Hi !
I would like to follow-up the "aliases" discussions by one on the "page types". The idea is that "constant" plugin calls would be very useful for a given type of pages in a Wiki. Examples: In a Wiki with "events", "white papers", "definitions", one would like: Page about an Event: list at the bottom of the pages referring to this event Page with a White Paper: Always a TableOfContent at the top; + list at the bottom of the pages referring to this White Paper about an Event: list at the bottom of the page of the pages referring to this event Page with a definition: At the top: links to broader terms; links to narrower terms At the bottom: list at the bottom of the pages referring to this definition For now, I am thinking of a <c:choose>, <c:when>, and <c:otherwise> in PageTop/PageBottom.JSP (one c:when per page type) Any better idea ??? Christophe P.S. To come nearer from a Semantic Wiki, page type is somewhat a must. |
|
|
Re: Page types
by Dirk Frederickx
::
Rate this Message:
Did you check the http://www.jspwiki.org/wiki/IfPlugin which should
give you quite some power too. You could eg consder to add this to [TitleBox] page or [CopyrightNotice] pages, which allows to do this kind of stuff without touching the template.jsp pages. dirk On Fri, Jul 4, 2008 at 3:32 PM, Christophe Dupriez <christophe.dupriez@...> wrote: > Hi ! > > I would like to follow-up the "aliases" discussions by one on the "page types". > > The idea is that "constant" plugin calls would be very useful for a given type of pages in a Wiki. > > Examples: In a Wiki with "events", "white papers", "definitions", one would like: > > Page about an Event: list at the bottom of the pages referring to this event > > Page with a White Paper: Always a TableOfContent at the top; > + list at the bottom of the pages referring to this White Paper > about an Event: list at the bottom of the page of the pages referring to this event > > Page with a definition: > At the top: links to broader terms; links to narrower terms > At the bottom: list at the bottom of the pages referring to this definition > > For now, I am thinking of a <c:choose>, <c:when>, and <c:otherwise> in PageTop/PageBottom.JSP > (one c:when per page type) > > Any better idea ??? > > Christophe > > P.S. To come nearer from a Semantic Wiki, page type is somewhat a must. |
|
|
Re: Page types
by Bob Paige-2
::
Rate this Message:
Christophe,
What if you wrote a page filter that included the semantic content? Tying this back to the Alias/Macro discussion, the content to be inserted could be in other wiki pages named after the different type, i.e. WhitePaper-Header, WhitePaper-Footer, Event-Header, Event-Footer, etc. The catch would be to identify what 'type' of page is being processed. The simplest solution is to base in on the page name. For example, whitepapers could always have a suffix of 'WhitePaper', i.e. 'Agricultural WhitePaper'. A more complicated solution would be to add arbitrary meta-data to the page and have the filter choose based on this meta-data. I see some discussion of metadata here (http://www.jspwiki.org/wiki/IdeasMetadata). Personally, I think the CSS approach makes the most sense. -- Bobman On Sat, Jul 5, 2008 at 4:42 AM, Dirk Frederickx <dirk.frederickx@...> wrote: > Did you check the http://www.jspwiki.org/wiki/IfPlugin which should > give you quite some power too. > You could eg consder to add this to [TitleBox] page or > [CopyrightNotice] pages, which allows to do this kind of stuff without > touching the template.jsp pages. > > > dirk > > > > On Fri, Jul 4, 2008 at 3:32 PM, Christophe Dupriez > <christophe.dupriez@...> wrote: > > Hi ! > > > > I would like to follow-up the "aliases" discussions by one on the "page > types". > > > > The idea is that "constant" plugin calls would be very useful for a given > type of pages in a Wiki. > > > > Examples: In a Wiki with "events", "white papers", "definitions", one > would like: > > > > Page about an Event: list at the bottom of the pages referring to this > event > > > > Page with a White Paper: Always a TableOfContent at the top; > > + list at the bottom of the pages referring to this White Paper > > about an Event: list at the bottom of the page of the pages referring to > this event > > > > Page with a definition: > > At the top: links to broader terms; links to narrower terms > > At the bottom: list at the bottom of the pages referring to this > definition > > > > For now, I am thinking of a <c:choose>, <c:when>, and <c:otherwise> in > PageTop/PageBottom.JSP > > (one c:when per page type) > > > > Any better idea ??? > > > > Christophe > > > > P.S. To come nearer from a Semantic Wiki, page type is somewhat a must. > |
|
|
Re: Page types
by Dirk Frederickx
::
Rate this Message:
@Christophe:
Here is how you could use the IfPlugin. Add following markup to the LeftMenu page. [{If var='pagename' contains='^WhitePaper-*' %%(background:yelllow;) [{TableOfContents }]/% }] dirk On Sat, Jul 5, 2008 at 1:46 PM, Bob Paige <bobpaige@...> wrote: > Christophe, > > What if you wrote a page filter that included the semantic content? Tying > this back to the Alias/Macro discussion, the content to be inserted could be > in other wiki pages named after the different type, i.e. WhitePaper-Header, > WhitePaper-Footer, Event-Header, Event-Footer, etc. > > The catch would be to identify what 'type' of page is being processed. > > The simplest solution is to base in on the page name. For example, > whitepapers could always have a suffix of 'WhitePaper', i.e. 'Agricultural > WhitePaper'. > > A more complicated solution would be to add arbitrary meta-data to the page > and have the filter choose based on this meta-data. I see some discussion of > metadata here (http://www.jspwiki.org/wiki/IdeasMetadata). Personally, I > think the CSS approach makes the most sense. > > -- > Bobman > > > On Sat, Jul 5, 2008 at 4:42 AM, Dirk Frederickx <dirk.frederickx@...> > wrote: > >> Did you check the http://www.jspwiki.org/wiki/IfPlugin which should >> give you quite some power too. >> You could eg consder to add this to [TitleBox] page or >> [CopyrightNotice] pages, which allows to do this kind of stuff without >> touching the template.jsp pages. >> >> >> dirk >> >> >> >> On Fri, Jul 4, 2008 at 3:32 PM, Christophe Dupriez >> <christophe.dupriez@...> wrote: >> > Hi ! >> > >> > I would like to follow-up the "aliases" discussions by one on the "page >> types". >> > >> > The idea is that "constant" plugin calls would be very useful for a given >> type of pages in a Wiki. >> > >> > Examples: In a Wiki with "events", "white papers", "definitions", one >> would like: >> > >> > Page about an Event: list at the bottom of the pages referring to this >> event >> > >> > Page with a White Paper: Always a TableOfContent at the top; >> > + list at the bottom of the pages referring to this White Paper >> > about an Event: list at the bottom of the page of the pages referring to >> this event >> > >> > Page with a definition: >> > At the top: links to broader terms; links to narrower terms >> > At the bottom: list at the bottom of the pages referring to this >> definition >> > >> > For now, I am thinking of a <c:choose>, <c:when>, and <c:otherwise> in >> PageTop/PageBottom.JSP >> > (one c:when per page type) >> > >> > Any better idea ??? >> > >> > Christophe >> > >> > P.S. To come nearer from a Semantic Wiki, page type is somewhat a must. >> > |
|
|
Re: Page types
by Murray Altheim-3
::
Rate this Message:
Bob Paige wrote:
> Christophe, > > What if you wrote a page filter that included the semantic content? Tying > this back to the Alias/Macro discussion, the content to be inserted could be > in other wiki pages named after the different type, i.e. WhitePaper-Header, > WhitePaper-Footer, Event-Header, Event-Footer, etc. > > The catch would be to identify what 'type' of page is being processed. > > The simplest solution is to base in on the page name. For example, > whitepapers could always have a suffix of 'WhitePaper', i.e. 'Agricultural > WhitePaper'. I've always found attempts at overloading use of the page name to be fraught with a lot of issues, not the least of which is to force page names sometimes into very ugly patterns just to conform to a specific need, then not fit a different need. One of the major benefits of faceted classification in library systems is to mitigate the fragility of enumerated classification systems, and while it's not using a controlled vocabulary, the WikiTag [1] function- ality (part of the CeryleWikiPlugins) does permit a separation of what you're calling "semantic content" from the page name. [{Tag WhitePaper }] Given you can query the TagManager [2] directly with a page to see if it has a tag (using a direct match or a regex, see [3]), it's possible to obtain a list of pages containing a tag, which could be used as input into another plugin (e.g., the IfPlugin) for further processing. > A more complicated solution would be to add arbitrary meta-data to the page > and have the filter choose based on this meta-data. I see some discussion of > metadata here (http://www.jspwiki.org/wiki/IdeasMetadata). Personally, I > think the CSS approach makes the most sense. If that arbitrary metadata were in the form of tags or say, a Dublin Core subject (keyword) list, yes. I don't understand the idea of using a stylesheet (presentation) approach to embedding meaning (semantics) that can be "reasoned" upon. On IdeasMetadata my note from 2005 might indicate some of the work I've been doing since then in developing an "Assertion Framework" that incorporates the TagPlugin in a more complicated system that permits assertions of the form [{Assert [BassettHound] KindOf [Dog] }] with a (relatively) simple inference engine permitting "answers" to queries. I'll be presenting a paper on this at Balisage 2008 in Montreal this August. Murray ---- PS. there is a known bug in the TagPlugin: the 'AND' logical operator is currently non-functional and will be fixed in an upcoming release. [1] WikiTags http://www.altheim.com/ceryle/wiki/Wiki.jsp?page=WikiTags [2] TagManager http://www.altheim.com/ceryle/wiki/Wiki.jsp?page=TagManager [3] javadocs, see hasTag(String pagename, String tag) http://www.altheim.com/ceryle/api/index.html?org/ceryle/wiki/plugin/tag/TagManager.html ........................................................................... Murray Altheim <murray07 at altheim.com> === = = http://www.altheim.com/murray/ = = === SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = = Boundless wind and moon - the eye within eyes, Inexhaustible heaven and earth - the light beyond light, The willow dark, the flower bright - ten thousand houses, Knock at any door - there's one who will respond. -- The Blue Cliff Record |
|
|
Re: Page types
by Bob Paige-2
::
Rate this Message:
I just did a little experiment regarding metadata and I am really liking the
CSS approach. Suppose you add something like this to your page: %%collapsebox !Metadata |tag|Whitepaper |tag|Event %% This defines two pieces of metadata. In this example they are both of type 'tag', but with different values. Metadata could have any name (and any number of columns!) but this illustrates how you could have multiple tags with the same name if you needed it. Notice that I used the 'collapsebox' CSS tag. This is part of the TableOfContents plugin, so it is already available. You need to provide a header (the "!Metadata" line) for the collapsebox to hook into. This gives us: 1. arbitrary structure over the metadata 2. metadata is easily editable 3. metadata is easily viewable/hideable 4. metadata is easily searchable (the standard search mechanism will find "tag|Whitepaper" in my example above One step further: Coupled with SearchPlugin you *almost* have a replacement for Categories or even TagPlugin. Once I had sample metadata as described above I tried using SearchPlugin to find only pages with certain tags (i.e. "[{Search query='Type|Whitepaper'}]"). While this works, there are a few downsides: 1. the output always contains the current page (since it satisfies the query as well) 2. the output is displayed in a search table with rankings 3. accidental hits are possible if your criteria are not sufficiently specific. The second point is interesting. My sample wiki has < 100 pages. Added some metadata to 5 pages and setup another page with the SearchPlugin. Even though these were the *only* pages with those tags, some were given a score as low as 19 and others as high as (only) 57. The score seems to be based on how large the page is. If the page contained only the metadata and one other link, the score was 57. If the page contained about a dozen lines with the metadata at the end, the score was 19. -- Bobman On Sat, Jul 5, 2008 at 7:46 AM, Bob Paige <bobpaige@...> wrote: > Christophe, > > What if you wrote a page filter that included the semantic content? Tying > this back to the Alias/Macro discussion, the content to be inserted could be > in other wiki pages named after the different type, i.e. WhitePaper-Header, > WhitePaper-Footer, Event-Header, Event-Footer, etc. > > The catch would be to identify what 'type' of page is being processed. > > The simplest solution is to base in on the page name. For example, > whitepapers could always have a suffix of 'WhitePaper', i.e. 'Agricultural > WhitePaper'. > > A more complicated solution would be to add arbitrary meta-data to the page > and have the filter choose based on this meta-data. I see some discussion of > metadata here (http://www.jspwiki.org/wiki/IdeasMetadata). Personally, I > think the CSS approach makes the most sense. > > -- > Bobman > > > > On Sat, Jul 5, 2008 at 4:42 AM, Dirk Frederickx <dirk.frederickx@...> > wrote: > >> Did you check the http://www.jspwiki.org/wiki/IfPlugin which should >> give you quite some power too. >> You could eg consder to add this to [TitleBox] page or >> [CopyrightNotice] pages, which allows to do this kind of stuff without >> touching the template.jsp pages. >> >> >> dirk >> >> >> >> On Fri, Jul 4, 2008 at 3:32 PM, Christophe Dupriez >> <christophe.dupriez@...> wrote: >> > Hi ! >> > >> > I would like to follow-up the "aliases" discussions by one on the "page >> types". >> > >> > The idea is that "constant" plugin calls would be very useful for a >> given type of pages in a Wiki. >> > >> > Examples: In a Wiki with "events", "white papers", "definitions", one >> would like: >> > >> > Page about an Event: list at the bottom of the pages referring to this >> event >> > >> > Page with a White Paper: Always a TableOfContent at the top; >> > + list at the bottom of the pages referring to this White Paper >> > about an Event: list at the bottom of the page of the pages referring to >> this event >> > >> > Page with a definition: >> > At the top: links to broader terms; links to narrower terms >> > At the bottom: list at the bottom of the pages referring to this >> definition >> > >> > For now, I am thinking of a <c:choose>, <c:when>, and <c:otherwise> in >> PageTop/PageBottom.JSP >> > (one c:when per page type) >> > >> > Any better idea ??? >> > >> > Christophe >> > >> > P.S. To come nearer from a Semantic Wiki, page type is somewhat a must. >> > > |
|
|
|
|
|
Re: Page types
by Murray Altheim-3
::
Rate this Message:
> Christophe Dupriez wrote:
>> Hi all! >> >> Thanks a lot for the healthy discussion and advices: I will let you >> know what I will have done finally (and practically!) >> >> Thanks Murray for the reference to "Balisage" conference in Montreal: >> http://www.balisage.net/At-A-Glance.html You're quite welcome -- glad to hear of your interest. Balisage is the new name for what used to be called Extreme Markup, which has been going on for many years each August, and represents many of the world's markup experts' latest work. >> To come back to the "tagging" concept, personnaly I see two different >> situations: >> * the classification of documents (the document "type") which determine >> its lifecycle (workflow), its access rules, its layout, etc. >> Each document having one class (type), possibly in a hierarchy of >> classes. What one might call "administrative metadata". >> * the indexation of documents ("keywords") which indicates its topics, >> processing status, linked places, epochs, people, organizations, etc. What one might call "classification metadata", though processing status is more properly in your first category of administrative. >> I see more the tags has parts of the indexation system than the >> classification. But a discussion on this may just turn like a discussion >> about typing versus untyping programming languages!!! I actually (as do librarians) differentiate between tags and facets. Tags are generally not from a controlled vocabulary, are generally added and used by users (rather than by librarians, publishers, administrators, etc.), whereas facets are a bit like tags but usually are from controlled vocabularies and themselves often fit into a hierarchy or ontology (the latter term I'm using colloquially to mean a graph structure of hierarchical as well as other relation types). I don't tend to mix this in with typing, but then again I am in a library environment where classification and categorization are the norm. Typing implies not classification but membership in a class, where "class" has some kind of formal definition, often set theoretic, collection-based, or some other form of mathetically-precise formalism. When we work with language we need to stop considering it as that formal -- it's not -- which is one of the reasons the "Semantic Web" is such dog's bollocks, i.e., one is simply using the wrong tool for the job. On the other hand, librarians have got it right: using human language as a way to classify human language, without any hand-waving about it having some kind of formal mathematical basis. >> To support classification also implies: >> 1) the Page Renaming is bug less even with uppercase accented letters, >> spaces and special characters: the page name embedding the class, it >> must be possible to change it without problems even for dictionnaries >> with complex names > >> 2) a solution is found for multilingualism (pages with different names >> in different languages but grouped has "equivalent by translation": >> references would consider pages in a "translation group" has being the >> same) The problem you're seeming aware of is that any given entity can be (and indeed, usually is) classified under multiple schemes; each can be considered as a different context. These different contexts can themselves be thought of in different contexts, recursively. Language is complex, and our use of it even more convoluted, especially since we're talking here about shared language. Computational linguistics used to make a lot of claims about machine "understanding" that have since been pushed out many more decades into the future. So while an entity (say, a book) might contain subjects of World War II, England, military history, predestination, the Tarot, it could contain many more depending on what a given culture or audience might find significant (an open question, to be sure). Therefore there might be classification metadata pertaining to its subjects (such as contained in a Dublin Core "Subject" term), as well as publication metadata (such as publication data (e.g., 1973), Author (e.g., Thomas Pynchon), Publisher (e.g., "Viking Press" or perhaps a person's name if self-published), and then all that administrative metadata (sometimes called "accession information"). And then there's the natural language of authorship ("English") as well as translation ("Arabic"). And a LOT more. I think between the two of us it's easy to see that this can get very complicated very quickly, and one of the purposes of a wiki is to try to provide a system that is both sufficient for one's needs but also as simple as possible. As engineers we tend to fail in the simplicity department. Tags have become popular because of their simplicity, but a big problem with tags is that they are an incredibly weak tool when used for classification of resources because they do not come (generally) from a controlled vocabulary, nor do they (generally) form a structure of their own, so there's no synonymy, no inheritance, etc. I've developed a system that forces each tag (as well as each Subject, Predicate, and Object in an Assertion) to be represented by a wiki page. I.e., an assertion or tag will fail if the page does not exist: the user gets an error message that includes a create page link. This is perhaps a bit more work than simply being able to list a bunch of words, but this forces documentation, hopefully minimizes spelling errors, and permits those tags (and Subjects, Predicates, and Objects) to themself be tagged or otherwise linked into the greater ontology via asserted relations, the whole wiki becoming a big user-generated ontology. This is what I'll be presenting on in August. a bit of wind, the tell-tales have now fallen... Murray ........................................................................... Murray Altheim <murray07 at altheim.com> === = = http://www.altheim.com/murray/ = = === SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = = Boundless wind and moon - the eye within eyes, Inexhaustible heaven and earth - the light beyond light, The willow dark, the flower bright - ten thousand houses, Knock at any door - there's one who will respond. -- The Blue Cliff Record |
| Free Forum Powered by Nabble | Forum Help |