Re: Proposal: register /.well-known/sparql with IANA

On 12/26/12 2:50 AM, Giovanni Tummarello wrote:
>>> A good argument ... for using sitemaps·
>>
>> Yes, those too.
>>
>> Fundamentally, we need to give discoverability and associated patterns a lot
>> more focus that has been done in the past. This is such a critical component
>> for making Linked Data easier to discover and appreciate.
>>
> good point re discoverability but you need clients too.

Yes, hence the need to push patterns clients can implement with ease.

>
>   we rolled out something very simple to understand and deploy in
> sitemap back in 2007 even.
>
> http://sw.deri.org/2007/07/sitemapextension/

Yes, but this addresses crawlers. We have to also look at clients that 
seek to do things such as:

1. profile discovery and profile data ingestion
2. sparql endpoint discovery -- covering basic sparql operations and 
sparql-fed .

>
> it has a concept of "dataset" (each can have a dump a sparql endpoitn
> and an extention used to serve resolvable uris)

Yes, but that's one profile. We need to build on this en route to 
broadening client profiles that can exploit Linked Data. As I've stated 
for a number of years, Linked Data enhances existing data access systems 
such as those associated with Open Database Connectivity (ODBC), Java 
Database Connectivity (JDBC), ADO.NET, JDO, OLE-DB etc..

ODBC is RDBMS specific and somewhat platform specific -- only useful to 
RDBMS app. developers.
JDBC is RDBMS specific and programming language specific -- only useful 
to Java app. developers .
ADO.NET is programming language (C/C++/C#) and platform specific -- only 
useful to ADO.NET framework based app. developers.
JDO is programming language specific -- only useful to Java developers 
working with this particular framework.

Linked Data delivers Open Data Connectivity without any of the platform 
and DBMS specificity outlined above. That said, all of the above have 
established patterns for data discovery by clients that are well 
understood by the massive installed bases that they cover. Each is at 
the very least 100 times the size of the current Linked Data developer 
base. Thus, its a no-brainer to build on the patterns established across 
these developer communities.

Some alignment tips:

1. Every Linked Data Entity URI is a Data Source Name (DSNs) -- natural 
segue for ODBC and JDBC  where DSNs are the standard mechanism for 
client connectivity to RDBMS data sources.

2. Every Linked Data Resource Address is a Data Source Locator 
(connection string) -- natural segue for ODBC, JDBC, JDO, ADO.NET, and 
OLE-DB .

3. /.well-known/sparql -- a natural seque for Query Service discovery 
and binding (these communities are looking for a mechanism for data 
service discovery and binding via SPARQL Service description documents).

4. /.well-know/data -- an even more generic mechanism for discovery and 
binding to Linked Data spaces (basically, the place for VoiD documents).
>
> a few data producers did actually implement it but the problem was on
> the consumer side.
>
> We consumed it ..okish at sindice.com but nobody else did, because
> there was no semantic web/linked data  client really ever.
> focus was on "publish your data" and something will happen,
>
> Can we think of a client that does something useful:
>
> * for real and not for a made up use corner case easily solved with a
> google search + 2 clicks.
> * connected to the reality of everyday browsing and web usage e.g.
> facebook, chrome browsing or mobile and not . So forget "alice wants
> to publish her own foaf file. "
> * generic enough and giving repeated value not to be a one off thing
> not only usable in super narrow contexts.
> * for real sustainability and growth, the value must be for both data
> publisher and consumer,should be directly measurable in ways people
> understand (roi etc)
>
> the client, the use case == the value , everything follows from there.
>
> Google schema.org etc clearly hits all the above except the client its
> THEM and everyone goes trough them.
>
> saying this in general for those not in specific to you kingsley :)

Okay, but we really have to look beyond Google. Their focus is crawling, 
ingestion, and indexing on a massive scale. Clients are typically 
looking to be much more mundane than Google.

>
> Gio
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen