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: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 13 Jan 2011 11:18:30 -0500
Message-ID: <4D2F25D6.60203@openlinksw.com>
To: Phil Archer <phil.archer@talis.com>
CC: Martin Hepp <martin.hepp@ebusiness-unibw.org>, public-lod@w3.org
On 1/13/11 6:04 AM, Phil Archer wrote:
> Martin seems to be fighting a lone battle, but fwiw I'll add my +1 to 
> his comments.
+1 for Martin's comments. Assuming my other comments didn't make this 
obvious :-)

> 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.

Yes, its a Super Key (in context of Linked Data), it can Lift (GET) 
Things up, and PUT Things down [1] .
> 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).

Yep, as per my comments about sponging.



1. http://www.youtube.com/watch?v=M-cpojkILO0 -- Nice URI Ad. 
Identifiers are Identifiers, URIs re. Linked Data are just Identifiers 
on Steroids

> 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.



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Thursday, 13 January 2011 16:19:02 UTC

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