Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to
his comments.
I do take the point that, in context, it's really nice if rdfs:seeAlso
gives a URI that provides more data in RDF and many applications will
make that assumption. But to /rely/ on that every time seems at odds
with the, AIUI fundamental notion, that a URI is an identifier and no more.
I'd say that if you see an rdfs:seeAlso property, sure, send an HTTP
request, but do it with a suitable accept header. If you get a 200,
great, add the data, but be ready to deal with a 406 (I've got it but
not in the format you have specified in your request).
Describing a URI with further triples is good, nothing wrong with that,
but to use that to decide whether or not to dereference an rdfs:seeAlso
URI means looking for a description of the linked resource and then
acting accordingly. That sounds like a relatively heavy bit of
processing that HTTP kind of takes care of for you.
Phil.
On 13/01/2011 10:10, 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.
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?
By the way, the problem of having to load huge amounts of data
following rdfs:seeAlso is not limited to PDFs - even obeying Tim's
proposal means there could be huge RDF graphs linked to via
rdfs:seeAlso, and that is of course conceptually perfectly okay.
After all, rdfs:seeAlso is not
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-) Data management and
data quality heuristics should not be solved at the conceptual level.
If old clients employ outdated heuristics, those clients should update
their heuristics, IMO.
Best
Martin
On 12.01.2011, at 16:13, Nathan wrote:
Hi Martin,
Martin Hepp wrote:
For my taste, using rdfs:seeAlso is perfectly valid (yet
suboptimal, because too unspecific), according to the RDFS spec:
http://www.w3.org/TR/rdf-schema/#ch_seealso
Quote: "rdfs:seeAlso is an instance of rdf:Property that is used to
indicate a resource that might provide additional information
about the subject resource.
A triple of the form:
S rdfs:seeAlso O
states that the resource O may provide additional information about
S. It may be possible to retrieve representations of O from the
Web, but this is not required. When such representations may be
retrieved, ***no constraints are placed on the format of those
representations***."
Generally it appears to me that rdfs:seeAlso is a property for a
machine to follow in order to get more information, and that much of
the usage mentioned in this thread requires a property which informs
a human that they may want to check resource O for more information
- essentially something similar to a hyperlink in a html document
with no @rel value.
Best,
Nathan
Please consider the environment before printing this email.
Find out more about Talis at http://www.talis.com/
shared innovation™
Any views or personal opinions expressed within this email may not be
those of Talis Information Ltd or its employees. The content of this
email message and any files that may be attached are confidential, and
for the usage of the intended recipient only. If you are not the
intended recipient, then please return this message to the sender and
delete it. Any use of this e-mail by an unauthorised recipient is
prohibited.
Talis Information Ltd is a member of the Talis Group of companies and is
registered in England No 3638278 with its registered office at Knights
Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA
22408, United States of America.
--
Phil Archer
Talis Systems Ltd
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org
