W3C home > Mailing lists > Public > public-lod@w3.org > January 2011

Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?

From: Phil Archer <phil.archer@talis.com>
Date: Thu, 13 Jan 2011 11:04:58 +0000
Message-ID: <4D2EDC5A.3040708@talis.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
CC: nathan@webr3.org, Tim Berners-Lee <timbl@w3.org>, Vasiliy Faronov <vfaronov@gmail.com>, Toby Inkster <tai@g5n.co.uk>, Peter DeVries <pete.devries@gmail.com>, public-lod@w3.org
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.


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
Received on Thursday, 13 January 2011 11:05:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:11 UTC