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 ingestion2. 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
smime.p7s
Description: S/MIME Cryptographic Signature
