W3C home > Mailing lists > Public > semantic-web@w3.org > September 2007

Semantic Sitemap extension version 0.93 is out. Now with an implementation

From: Giovanni Tummarello <giovanni.tummarello@deri.org>
Date: Fri, 7 Sep 2007 18:47:39 +0100
Message-ID: <210271540709071047i7b20ee11r53235241c58f014b@mail.gmail.com>
To: "Linking Open Data" <linking-open-data@simile.mit.edu>
Cc: semantic-web@w3.org, deri.ie-research@lists.deri.org, "Leandro M. López (inkel)" <inkel.ar@gmail.com>
Greetings all..

a new version of the Semantic Sitemap extension is available at

The semantic sitemap is meant to simplify and increase efficiency in
accessing and indexing sites which offer a large amount of semantic data.
Use cases include semantic web clients and search engines.


we now have an implementation in java, courtesy of Leandro Lopez (inkel).
The implementation currently checks for the existence of a Sitemap and
provides a wrapper to the fields.  A next version of the implementation
currently being worked on will also support all the known quad serialization
formats as described in the current specs. At that point it should be really
easy enough to integrate this with any client or server implementation.

In detail what's new:

* dataset "access options" instead of "representations",
* MUST contain the same semantics than the dump loosened to SHOULD contain,
* robot.txt example,
* Refactored the text,  now each tag description also contains the
* Explained and made consistent use of the term URI/URLs,
* Examples online
* Implementation


should we have an attribute to specify which format the dump is in?
currently we think that if we do give a very flexible implementation then
there is no need. In theory web architecture standards say that one should
only have a URL and that format are negotiated. In PRACTICE this doesnt
happen for formats which are relatively unknown.. not without configuring
the server which is not something we want to force people to do. so in
PRACTICE it would seem appropriate to have the format specified in the
format to make it easy for those writing the client.
but again if we do provide a smart enough client in a public domain
implementation then ...


thanks to the many who contributed to this release, looking forward for more

Received on Friday, 7 September 2007 17:47:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:02 UTC