--->> > I am not sure if I understand what you wrote. Are you saying that I should > not make all data available through the SPARQL endpoint?
I think Pieter had a better formulation…that is having the datadumps next to the SPARQL endpoint.. > >>> >>> I now wonder how I can publish the fact that my SPARQL endpoint has a LIMIT >>> and that is has a certain value. >> >> I guess it will all depends on your endpoint backend (fuseki, virtuoso, >> OWLIM ,etc). Some comes with configuration files where you can set the limit >> of the maximum results. > My question was not about how to configure limitations on the endpoint > backend, but how to make those limitations known to users of the backend. I understand better now ;) I have a similar issue while using a Linked Data Platform relying on sesame, where I still have to find out what is the maximum results allowed by sesame. So, yes having an explicit knowledge of those limitations could help the users. > > Perhaps I need to elaborate on what I am thinking about... Let's say a user > agent that is browsing or crawling the web comes across a dataset that is > somehow interesting. Using the VoID metadata the agent can discover the URI > of the SPARQL endpoint. With that knowledge, the agent can start querying the > dataset for those data that it is interested in. Now it would be very nice to > know the service limitations before the agent starts querying. Perhaps the > service has some kind of access control, perhaps it is scheduled to be > offline at the moment, perhaps it can return no more than 100 results per > request... If limitations like these are known to the agent, the changes of > successful communication will be much increased. And perhaps it will take > some weight of the server too. Well, apart from dcat, sd and voID mentioned, I can suggest this api vocabulary [1], with properties like api:maxPageSize, api:endpoint. Best, Ghislain [1]http://linked-data-api.googlecode.com/svn/trunk/vocab/api.ttl#
