Re: The king is dressed in void

Most of the functionality is there. I disagree with the artificial
restrictions on sparql graph names being either singular or completely

Also, it would be an improvement to specify this information in RDF
rather than in XML as sitemaps does if people are expecting to be able
to utilise RDF stores for querying of the information. If we were just
stuck with sitemaps.xml as the final point we also couldn't extend it
easily to provide rdf vocabulary terms such as dc and skos. Have
sitemaps.xml extensions been used for more than providing links to
data dumps? Ie, has someone actually used the slicing and sparql graph
parts to describe a data set?



2008/6/13 Giovanni Tummarello <>:
> All of your described functionalities are a subset of what semantic
> sitemaps are for [1].
> Specs aside, the paper [2] might be of interest to some is that we
> went to some distance in conceptually explaining what publishing and
> retrieving rdf
> data on the web means, e.g. using "linked open data" paradigm but not only.
> Giovanni
> [1]
> [2]
> On Thu, Jun 12, 2008 at 11:19 PM, Peter Ansell <> wrote:
>> I see VOID as going past the need to have a search engine in order to
>> decide which sparql endpoints you need to use to effectively make
>> particular queries based on sample graphs provided by either SPARQL
>> construct queries on the dataset sparql end point or by way of an
>> example document specifying typical rdf statements that are contained
>> in a data set.
>> Your method does not currently enable someone to backtrack to which
>> endpoints they should use to get more information about someone if
>> they don't just want to do a text search, or rely on someone pre
>> indexing billions of rdf statements for them. Linked Data should be
>> about self-discovery. If someone ever finds a URI used on the semantic
>> web they can now find a way to a sparql end point with more related
>> information. Ie, if you found
>> as a URI on the web and
>> had not yet indexed it for you then you could discover it
>> by chopping off the path and accessing the robots.txt file provided by
>> that domain, a method currently used by web 1.0 search engine
>> crawlers. Then you can discover the end_point and a typical example,
>> along with provenance and subject information by using the void method
>> (robots.txt->sitemap.xml->void rdf->either SPARQL CONSTRUCT or example
>> file). Of course, this mechanism will not work directly for
>> users.... but it is a good start as far as I can tell for datasets
>> which utilise their own domains for naming and hosting. users
>> could be supported if you acknolwedge that the real provider is the
>> one redirected to by the 302 redirect from and you could
>> start the discovery process there.
>> The method of discovering this information,  don't require an extra
>> level of complexity as the void rdf simply adds the sparql endpoint
>> information, example information, and provenance information.
>> I don't see VOID as having more than one class and two or three
>> properties when it is eventually created.
>> Class: void:Dataset
>> Property: void:sparql_end_point, void:example_file, void:example_uri
>> (which you can use with a SPARQL construct on the
>> void:sparql_end_point in order to get the same as a void:example_file)
>> The rest of the descriptions seem to be allowed for by current
>> vocabularies such as foaf and dc so the actual specification will be
>> very highly modular and hence easy to implement and agree on IMO.
>> Cheers,
>> Peter
>> 2008/6/12 Giovanni Tummarello <>:
>>> Wasnt RDF all aabout being self describing?
>>>  if i say "giovanni works in research" .. do i really need a
>>> vucabolary that says "this rdf contains informations that describe
>>> what people claim to be working on" that's a suicide. If this is the
>>> case (which i totally dont believe) then the king is seriously naked
>>> and there is no hope whatsoever that RDF is going to have any
>>> relevance (and there i say it)
>>> to find one such file, instead of having to invent agree and markup
>>> i'd say its much easier to do something like [1] or [2].
>>> this is not marketing. its a plea to NOT jump on more layers of stuff
>>> when the previous layers have really to show there value and
>>> adoptability still. Solve some simple use cases first then jump to the
>>> more complex one.
>>> Giovanni
>>> [1]*
>>> or
>>>  (documents which contain statements in which someone claims to be
>>> knowing richard)
>>> [2]

Received on Thursday, 12 June 2008 23:44:25 UTC