Martin Hepp wrote:
Hi Nathan:
There are other ways of looking at this, remembering we're in the
realm of machine readable information and the context of RDF.
rdfs:seeAlso is used to indicate a resource O which may provide
additional information about the resource S - information in this
context being rdf, information for the machine - so we can say that if
O points to a resource that doesn't contain any information at all (no
rdf, or isn't the subject of any statements) then we've created a
meaningless statement, it may as well be { S rdfs:seeAlso [] }
One could easily suggest that it's good for RDF Schema properties to
have some use in RDF, and thus that if rdfs:seeAlso is used in a
statement, that it should point to some "information", some rdf for
the machine, otherwise it's a bit of a pointless property.
Given the above, we could take the meaning of the sentence "no
constraints are placed on the format of those representations" and
assert that this simply means that RDF/XML is not required, and that
any RDF format can be used.
I don't buy in to restricting the meaning of "data" in the context of
RDF to "RDF data". If the subject or object of RDF triples can be any
Web resource (information and non-information resource), then the range
of rdfs:seeAlso should also include information resources (i.e., data)
of a variety of conceptual and syntactic forms.
The "data" part of "linked data" is not generic, machine accessible !=
machine understandable, and that's what this is all about.
"linked data" is not some term for data with links, it's an engineered
protocol which has constraints and requirements to make the whole thing
work.
We cannot build a web of data (machine understandable dereferencable
data) without these constraints.
And PDF, HTML without RDFa as well as images clearly qualify as data.
They are also clearly machine-accessible. If you are still not
convinced: What about CSV files or text files containing ACE (controlled
English), or OData / GData?
I'm far from convinced, and have discussed this at length w/ Kingsley
and others.
A three column CSV is not linked data, yes you can take linked data and
format it in a 3 column CSV, and yes with some out of band knowledge
about a particular CSV you can /convert it to/ to RDF, this is not true
for /all/ csv files and only ever works if you have prior knowledge of
the particular file being considered - that is to say, we can't build a
web of data by publishing csv files, or traverse a web of data by
setting our Accept headers to "text/csv" and hoping that any data
received matches our three column constrains (and hoping again when it
does that it actually is something we can use and not just "x x x"). The
same is true of text files containing ACE.
As for OData and GData, sure it is more linky, and looks more like RDF,
but it's not, and the rabbit hole runs much deeper with these two but
essentially it's the difference between people making open world
semantics and making statements they intended to make, and people having
RDF gleaned from data they've put out which may take on a different
meaning when in RDF other than that which was intended.
Ultimately, a big part of the linked data protocol is having machine
readable and understandable data in negotiable well defined formats
available at dereferencable http and https scheme URIs - if you drop any
one of those elements it's simply not "linked data"
Perhaps this points to a need to standardize Linked Data as a protocol.
Best,
Nathan
