Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)

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

Received on Thursday, 13 January 2011 17:05:19 UTC