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

Re: Announcement: Firefox Navibar Extension 0.10

From: Dan Brickley <danbri@danbri.org>
Date: Mon, 23 Jan 2006 10:10:25 -0500
To: Reto Bachmann-Gm??r <reto@gmuer.ch>
Cc: "siebeneicher@oaklett.org" <siebeneicher@oaklett.org>, semantic-web@w3.org
Message-ID: <20060123151025.GA3243@postdiluvian.org>

* Reto Bachmann-Gm??r <reto@gmuer.ch> [2006-01-23 15:51+0100]
> 
> siebeneicher@oaklett.org wrote:
> >...
> >>Maybe allowing to set the focus on one node in the tree so that this 
> >>nodes the becomes the root of a "forward-tree", as well as a 
> >>"backward-tree" showing the resources which do link to this blog-entry?
> >
> >NNS(Navibars Sitemap format) use the map:container and map:embedded 
> >elements to realize exactly this(tree's behind tree's). Navibar do not 
> >have implemented this feature yet, but its a good idea. As you say, 
> >the current Sitemap proposal above does the job with the rdfs:seeAlso 
> >but i would also like to see to include parts of a tree from an other 
> >source.
> With rdfs:seeAlso the client is encouraged to download the triples from 
> the other source, what is important is that the subject of the 
> rdfs:seeAlso statement is present in the other model as well (and that 
> it can be determined which one it is).
> >
> >The idea at the following example was to include a Sitemap from 
> >http://www.osar.ch/eductation-sitemap which replaces or extends the 
> >content of the children element. This would help splitting the content 
> >of a Sitemap and gives the chance to include Sitemaps and 
> >Lists(rss/atom ??) from another domains.
> >
> >> <SiteMapEntry>
> >>    <rdfs:label>Flight - Asylum - Integration</rdfs:label>
> >>    <page rdf:resource="http://www.osar.ch/education" />
> >>    <children rdf:parseType="Collection" 
> >rdfs:seeAlso="http://www.osar.ch/eductation-sitemap" />
> >> </SiteMapEntry>
> >
> >The rdfs:seeAlso is not good here, i would use "src" or the atom 
> >ontology, what do you think about this?
> The rdfs:seeAlso is not good here because it is invalid RDF/XML in that 
> position, it is  unclear what you want to be the subject of the 
> rdfs:seeAlso statement (same issue with atom:link).
> 
> In the example I proposed in my last mail:
> <SiteMapEntry>
>  <rdfs:label>Flight - Asylum - Integration</rdfs:label>
>  <page rdf:resource="http://www.osar.ch/education" />
>  <rdfs:seeAlso rdf:resource="http://www.osar.ch/eductation-sitemap" />
>  <children rdf:parseType="Collection" >
>         .....
>   </children>
> </SiteMapEntry>
> 
> the subject is the SiteMapEntry, however it may be unclear for the 
> consumer, which is the equivalent SiteMapEntry in the model refernced by 
> seeAlso (unless page is an IFP, which conflicts with the requrement that 
> multiple navigattion-maps for the same set of pages should be possible). 
> So I guess the following would be better:
> 
> <SiteMapEntry>
>  <rdfs:label>Flight - Asylum - Integration</rdfs:label>
>  <page rdf:resource="http://www.osar.ch/education" />
>  <children rdf:parseType="Collection" >
>         .....
>   </children>
> </SiteMapEntry>
> 
> <rdf:Description rdf:about="http://www.osar.ch/education" >
>      <rdfs:seeAlso rdf:resource="http://www.osar.ch/eductation-sitemap" />
> </rdf:Description>
> 
> >
> >By the way, the next time i write a spec by my own i will definitly 
> >talk to other about that, it was a big mistake to recommend NNS 
> >without showing the working draft first. A while i ask myself if there 
> >are other ways to distribute/share a new Sitemap Specification because 
> >i am afraid of having the specifications at 
> >http://navibar.oaklett.org/specs/. I am the owner of 
> >http://navibar.oaklett.org but i do not want to own the specification 
> >when it is used by many others out there. Are there ways to give it a 
> >more neutral touch?
> I have the same problem, and no solution yet.

This is one of the roles W3C has in the world. While it would be a 
shame if the community (and wider industry) concluded that the only
trustable RDF vocabulary is one with http://www.w3.org/ at the start 
of its URI, ... there is the potential (eg. RDF calendar, exif, geo) for
collaborative ideas from this Interest Group to find a namespace home
at W3C. We have in SWIG the loose notion of a 'taskforce', as well as (more
recently) the concept of a W3C Incubator Group. As of now, there are 
no Incubator groups launched. The basic idea is that these incubators
are lightweight efforts, instigated by the W3C membership rather than
its paid staff, and that they can explore new areas that could be the
basis for future Working Group activity. The Incubator Activity hasn't
been announced very loudly, but you can find it in Google :) More info
here: http://www.w3.org/2005/Incubator/  --- basically, to start 
an incubator, find 3 or more W3C Members to write a charter. 

Back on the topic of sitemaps, a related piece of work is the
link-typing in HTML. I've started an RDF vocab to capture XHTML2 link
types, as part of the SW Best Practices WG collaboration with the 
HTML Working Group. See http://www.w3.org/2005/05/hrel/ for a 
draft-draft work in progress (noting that it hasn't received full review
yet by the RDF-in-XHTML taskforce, let alone by the WG, and hasn't been
published as a W3C Technical Report).

My take on sitemaps, after some early-ish work with Libby Miller in the
DESIRE project, and from following the Mozilla designs, is that it is 
a devilishly hard problem to scope. But also one with huge potential.
MOre on this another time :)

cheers,

Dan
Received on Monday, 23 January 2006 15:10:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:11 UTC