Argumentario APIs Vs Linked Data…

Link:

1. http://en.wikipedia.org/wiki/Entity-attribute-value_model

Kingsley

*) You take into account that choosing linked data over CSV comes with added costs for the publisher. You omit that in the current state of the world, it comes with added costs for the consumers as well. Most developers don’t know much about RDF and surrounding tools and standards, so they have to learn about it in order to consume your dataset. These costs can easily outweigh potential benefits. Of course, the mission of the linked data community is to change that fact by popularizing RDF technologies and standards, so that might not be true anymore 5 years from now.
*) I guess interlinking could also be partially be tackled by adopting simple conventions for adding URLs and URIs as values ins CSV rows. For example, referencing Wikipedia URLs. CSV files and rows in these files could then be related to each other via shared Wikipedia references. This would not be that different from the current Linked Data cloud, where DBpedia acts as a central hub for many other datasets.

Cheers,
Matthias

Inserting EAV into the Linked Data conversation is about creating foundation for understanding roots of the model that drives RDF data representation formats. Basically, how its been enhanced by the addition of URIs re., basic RDF and generic HTTP URIs re. RDF based Linked Data.

Kingsley

To my knowledge EAV has no equivalent community like OpenRDF.org supporting an open source reference implementation; there is no Python library like RDFlib for working with EAV; there is no standardized set of attributes like RDFa for embedding assertions within Web documents…

You’ve stated above,

…EAV model data can be expressed in a myriad of representation formats (which includes the RDF family)…

From a practical standpoint, what are those formats and why should adopters care?

- the data I was looking for;
- an identifiable source;
- related data (so eg I search for population of london and get a dataset that contains the population of other places too).

To the extent that a CSV table is a full text searchable file, if it has been indexed I can throw in my arbitrary and possibly not very good search terms, and maybe the index will throw a dataset back (eg as a CSV file) that contains the datum I want.

In terms of discovering the data, this is really hit and miss, really flaky, and dead simple.

Cf. how many people would use Google books or Amazon’s one search box rather than enter the right things in the right boxes in a Library OPAC (or hack an even purer Z39.50 query from a terminal command line (can you even do this?!))

I know I come coming across as anti-SPARQL and anti-Linked Data, but I’m not. I just think that the barriers to entry are too many at the moment for enough people to see how they might benefit…

IMHO, if the datastores started publishing interesting and maybe frequently requested data views as full text searchable and discoverable csv, and alongside linking to a sparql query that would return that same data in a richer form, it would help….

Then I as a novice an stumble across the thing I was maybe looking clumsily for, do what I want with it, maybe realise it’s not quite what I want see the Sparql, not understand a world of what it says but see one part of it that I can guess at changing (hmmm…. /bluerghhh London wibble/…. I wonder if /bluerghhh Manchester wibble/ works too…? Hmmm, looks like between two dates? what happens if i chance those dates… and so on…)

I think in terms of weird surface areas relating to discoverability and usability of this stuff. CSV is discoverable over a large area, (search engines can handle it, local datastores, etc); it’s useable over a wide area (lots of tools import it, lots of peope use tools that can import it).

You’re a scientist, I’m a pragmatist. But you’re maybe thinking a little bit too like the librarians (we’ll be having no tags here, we just want proper controlled vocabularies) as they upheld the proper way of doing things and they users Googled ?

Doh! I don’t mean to say Linked Data is not the way forward, I just don’t think it’s yet a representation that large numbers of people would feel comfortable or capable of working with, given what they currently know, what they currently do, and they culturally currently do it…

In my view the question is analogous to that of (web) API design: ultimately, to be success, it must be usable!

In his great Javapolis keynote, How to Design a Good API and Why it Matters Josh Bloch of Google laid out these characteristics of a “Good API”:

• Easy to learn
• Easy to use, even without documentation
• Hard to misuse
• Easy to read and maintain code that uses it
• Sufficiently powerful to satisfy requirements
• Easy to extend
• Appropriate to audience

Bloch argues that with these properties in mind, a public API can be an organization’s “greatest asset.” I would argue that for data-intensive organizations, datasets published as linked data with these same characteristic could well be their most valuable asset!

To cut a long story short. RDF formats provide one of several vehicles for publishing Linked Data on public or private HTTP based networks.

RDF isn’t accepted as a Data Model, its a Data Representation mechanism (Markup). The base Data Model is EAV (with EAV/CR when going into the realms of TBox and ABox partitioning). Linked Data adds the use of HTTP based URIs for Names re. Entity, Entity Attribute, and Entity Attribute Value slots re. the base models 3-tuple structure.

EAV model data can be expressed in a myriad of representation formats (which includes the RDF family).

RDF has its own merits wrt. to real object modeling fidelity. Thus, we don’t need to conflate Data Representation and Data Model in order for RDF to succeed, based on its on tangible virtues.

Important Note:
TimBL’s original design issues doc never made mention of RDF or SPARQL as mandatory. Even today, I strongly believe his current edition references RDF and SPARQL (in parenthesis) as examples of relevant standards that aid publication of Linked Data.

Links:

1. http://bit.ly/cA0zxw — Data 3.0 Manifesto (decouples RDF from Linked Data).