Hi Kinglsey, Kingsley Idehen wrote:
When our engine describes entities it can publish these descriptions using variety of structured data formats that include RDF. The same thing applies on the data consumption side. Basically, RDF formats are options re. Linked Data (the concept).
A generic problem here, when using non RDF types with Linked Data over HTTP, is that there's currently no way to indicate that a resource is/has a set of machine readable "linked data" variants, in many cases it is useful to publish and consume with linked data in CSV format and related (as you well note) - but without prior out of band knowledge that the representation contains, or is, linked data, the machines are pretty much screwed. Typically the RDF variants don't have this problem because the media type sets the expectation, so you can conneg on an RDF type and know your getting back "linked data", you can't do this with CSV and related with any expectation that you'll get back "linked data" - thus, if there was some way to mark the set of representations given upon dereferencing a URI as linked data, containing rdf, rdfable 3 tuples, or a view thereof, it'd be a lot friendlier to the web of data in general.
A typical approach would be to register new mediatypes, +variant kinds, for instance text/rdf+csv or such like, but these types wouldn't be well known throughout the internet, served correctly by default in the likes of apache, or handed off to the correct consuming programs by user agents - I'll leave it there, without a proposal, but some indication to the machine would/will be needed to make this approach friendlier for the web.
and as an aside: I do worry a little that there may be some overloading of terms going on here, Linked Data (the concept) and Linked Data (the protocol) - I'm unsure exactly how to define Linked Data (the concept) but assuming you're referring to a broad range of EAV variant 3-Tuple based data with URIs.
Best, Nathan
