One obvious solution is to use an extra triple to indicate that the URL
is a serialisation of some triples. eg.
<rdf:Description rdf:about="...URI-X...">
<rdfs:label>the name of the thing for which more data is
available</rdfs:label>
<rdfs:seeAlso>
<rdf:Description rdf:about="...RDF-URL...">
<rdf:type
rdf:resource="http://purl.org/xtypes/Document-RDFSerialisation"; />
</rdf:Description>
</rdfs:seeAlso>
</rdf:Description>
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
--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/
