W3C home > Mailing lists > Public > semantic-web@w3.org > January 2006

Re: Announcement: Firefox Navibar Extension 0.10

From: Reto Bachmann-Gmür <reto@gmuer.ch>
Date: Tue, 10 Jan 2006 11:42:57 +0100
Message-ID: <43C38FB1.6080908@gmuer.ch>
To: "siebeneicher@oaklett.org" <siebeneicher@oaklett.org>
CC: semantic-web@w3.org

siebeneicher@oaklett.org wrote:
> Reto Bachmann-Gmür schrieb:
>> <SiteMapEntry>
>>    <rdfs:label>Flight - Asylum - Integration</rdfs:label>
>>    <page rdf:resource="http://www.osar.ch/education" />
>>    <children rdf:parseType="Collection">
>>       <SiteMapEntry>
>>          [...]
>>       </SiteMapEntry>
>>    </children>
>> </SiteMapEntry>
> I am not introduced to the need of this example, could you tell me 
> what should it solve, or better asked, in what matter could users 
> "act" with a software that is using this example. Is it the way 
> Navibars tree do it? A simple tree, once all branches are opened by 
> the user, he has a look at the whole tree hierachy and can choose the 
> webpage he wants. The tree is presented to the user allways in the 
> same structure until the source changes. Let me say, the structure of 
> a tree is like a graph where the rule is, that a node anywhere in the 
> whole graph, can only have one parent, but more than once children.
My hope is that a nice application like navibar could foster the 
deployment of content making the semantic web grow. As requirement to 
format I would see:

- free merging of navigation graphs
- multiple navigations for the same set of pages
- easy to understand and use
> During the design phase of the NNS Sitemap i decide to use a simple 
> and "flat" tree representation only for practical reasons. I also 
> thought of a navigation tool going a more semantic way. But hey... 
> what damn does the "semantic way" mean? Today, i think this way is 
> when users ask the internet a clever question and get a clever answer.
Imho, things that are not the semantic web way in 
http://navibar.oaklett.org/sitemap.rdf are:
- Lack of type for the classes
- Use of rdf:Seq which makes aggregation harder than with 
- Using plain-literal URIs while in fact the named-resource is meant
- Unnecessary naming of resources with URNs

In my example:
- The resources have a type (SiteMapEntry, but would probably better be 
- Instead of "identifier" a "page" property points to the page (which is 
a resource)
- parseType="Collection" instead of Seq
- rdfs:label / dc:title: question of taste I guess, could live with 
dc:title ;-)

Like your vocabulary it supports an arbitrary graph-structures including 
circles, and I don't think that it would be any harder to use for an 
application like the current version of navibar, but more likely to be 
of use for more generic aggregators.

> This means practicaly, the navigation tool offers the user a more 
> fluid structure of the content of a website. A rule is, that the 
> structure of the view is changable because the users view -- depending 
> on the question the user asks -- is also changable. If the user is 
> "asking" a soccer website the question: "worldcup 2006", the structure 
> of the view of webpages could be:
> ....
Another use-case, where aggregability and graph structure become 
important would be a tool (navibar 2 ?) to visualize an navigate through 
a blog-discussion on multiple servers.

Received on Tuesday, 10 January 2006 10:43:23 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:44:55 UTC