Re: How will the semantic web emerge: SPARQL end point and $$€€

I see two major hurdles for a SPARQLing web, and both are takes on
complexity.

First, reluctance by businesses (or organizations in general) to expose
their information to such arbitrary queries. Sure, SQL's in wide usage,
but not exposed to the general public!

Part of this is due to difficulties in segregating public data from
private data -- something that will hopefully be easier in the semantic
web. Are there any efforts to create simple declarative "filters" for
RDF data?

But another part is due to understandable reluctance to allow queries of
arbitrary complexity. Two things will distinctly ameliorate this: a
switch you can turn on to reject queries that are "too complex" (for
some value of complex that can be calculated for a given query), and a
way to set a maximum resource usage per query in SPARQL endpoint
configuration (along with rate restrictions on queries, of course).

The second hurdle is also complexity related, but on the querying end.
How do I know the sorts of queries meaningful to perform on an endpoint?
Sure, look at the ontology, but that is not always useful -- for
instance, some ontologies rely on the dublin core elements directly to
carry meanings that are really more specific, and that often can't
really be "seen" in an ontology (a good argument for subclassing
properties). It may well be useful to create prescriptions for
constructing queries from ontologies, and make a GUI allowing one to
apply those prescriptions, and APIs.

That means there's one missing point to the SPARQL story -- a way to
denote both all ontologies the endpoint is using, and all ontologies
(likely one or two) that are relevant to the "point" of the endpoint. I
include this last because many SPARQL endpoints will expose data for a
number of ontologies -- but the data most people querying the endpoint
will be interested in will be from one or two ontologies.

Actually, I haven't read the SPARQL specs in enough depth to know there
/isn't/ a solution to this somewhere. One obvious one presents itself if
none exists currently, though -- have RDF triples in there with the
SPARQL endpoint URI as the subject, appropriate predicates for the
various ontologies exposed, and using the ontology URIs (same as for
imports) as objects. Then people can just query the SPARQL endpoint for
the information. These triples would likely be "mixed in" with the
datastore triples based on information in a config file.

Even with these dealt with, there are major hurdles to widespread SPARQL
adoption. I am not entirely convinced a significantly simpler query
protocol (I hesitate to say language, as it would likely be too simple
to obviously need the moniker), allowing the small class of most common
RDF queries, would not have a better chance of success. We shall see,
though.

Russell

Henry Story wrote:

>
>
> On 21 Dec 2005, at 19:26, Joshua Allen wrote:
>
>> I would draw exactly the opposite conclusion from the real-world data.
>
>
> I am not sure what the opposite conclusion is that my arguments help 
> you reach.
>
>> However, I don't have any particular bias or religion to boost, so 
>> my opinion may be unanchored.
>
>
> Neither do I. We are both trying to determine where the future is 
> going, and reasonable people can easily and rightly agree to disagree 
> on that, as it is mostly indeterminate. Guessing the future correctly 
> can make a lot of difference in how much money ends up in one's 
> pocket :-)
>
> I think at the minimum it is worth considering that SPARQL + an 
> ontology can replace a lot of what the complex SOAP web services are 
> trying to do. And even simplify the RESTful web services supported by 
> Amazon. This is because the Ontology, the query language, and the 
> results are beautifully complimentary and fundamentally tied into the 
> fundamental web archictecture construct: the URI.
>
> Henry Story
>
>>
>>> -----Original Message-----
>>> From: Henry Story [mailto:henry.story@bblfish.net]
>>> Sent: Wednesday, December 21, 2005 10:21 AM
>>> To: Joshua Allen
>>> Cc: tim.glover@bt.com; fugu13@mac.com; fmanola@acm.org; semantic-
>>> web@w3.org
>>> Subject: Re: How will the semantic web emerge: SPARQL end point  and
>>> $$€€
>>>
>>>
>>> On 21 Dec 2005, at 19:08, Joshua Allen wrote:
>>>
>>>>> worth looking at this. If I were Barnes and Noble of la FNAC I  would
>>>>> try this out, before Amazon gets there.
>>>>
>>>>
>>>> This motivation only works if there is credible evidence that
>>>> Amazon is preparing to launch SPARQL endpoints, though.  And even
>>>> then, only if there is evidence that such endpoints would see broad
>>>> adoption.
>>>
>>>
>>> Amazon as you point out below, has published web services, so that is
>>> a good reason to try to do better. Furthermore those services are
>>> more difficult to establish as you have to specify the query language
>>> as well as the xml format. With RDF and SPARQL most of these problems
>>> are already solved for you in a standard way. So life is a lot
>>> easier. You have a much more powerful query mechanism, a much cleaner
>>> semantics. No need to re-invent the wheel.
>>>
>>>>> Once more groups get their SPARQL end points out, I forsee that 
>>>>> major
>>>>> players will wish to standardise on some ontologies to:
>>>>
>>>>
>>>> I believe we have enough specific evidence to counter this
>>>> prediction already.  Amazon has already exposed its business data
>>>> in a variety of flavors:
>>>
>>>
>>> Exactly. That proves the point that if you put data on the web that
>>> has value, people will use it whatever the obstacles are, as long as
>>> it the obstacles are not bigger than the time required to invest in
>>> accessing it. Amazon had to use RESTful web services, invent an XML
>>> format and a query language as at the time they put their service
>>> online SPARQL did not exist. All of this comes out  automatically
>>> from having a good ontology. The query mechanism is immediately
>>> defined, and the whole thing is self documenting.
>>>
>>>
>>>>
>>>> 1) Web services with loose contract (POX over HTTP)
>>>
>>>
>>> Most successful for complex apps.
>>>
>>>> 2) Intermediate format -- RSS using some simple, well-known 
>>>> extensions
>>>
>>>
>>> most successful for very simple keeping up to date apps.
>>>
>>>> 3) Web services using tighter schema (SOAP and WSDL)
>>>
>>>
>>> Not successful. Too complicated. On the way to extinction.
>>>
>>>> Can you guess the relative adoption of each style?  This is a
>>>> pattern we see played out across the industry.
>>>
>>>
>>> So my point is that SPARQL will replace 1. It is RESTful enough and
>>> avoid having to invent a query language and an XML format.
>>>
>>> Henry Story
>>> http://bblfish.net/blog/
>>
>>
>
>

Received on Wednesday, 21 December 2005 19:56:13 UTC