Hi Tim:
On 13.01.2011, at 12:29, Tim Berners-Lee wrote:
On 2011-01 -13, at 05:10, Martin Hepp wrote:
I don't buy in to restricting the meaning of "data" in the context
of RDF to "RDF data".
You can define "data" however you like for the purpoes of an
argument, but with
nothing to do with how rdfs:seeAlso is defined.
If the subject or object of RDF triples can be any Web resource
(information and non-information resource),
That is true.
then the range of rdfs:seeAlso should also include information
resources (i.e., data) of a variety of conceptual and syntactic
forms.
That does not follow at all. You just made that up.
No, I quoted the official W3C specification for RDFS. It does not, or
at least not very clearly, indicate that the range of rdfs:seeAlso is
the set of RDF resources.
It totally depends on the semantics we define for rdfs:seeAlso.
This is why I quoted the RDFS spec.
Now, we could define many things, but the older FOAF practice has
encouraged many people to use it as part
a protocol in which the writer writes
<#i> foaf:knows [ foaf:name "Fred"; foaf:personalMailbox mailto:[email protected]
; rdfs:seeAlso <http://acme.org/people/fred>.
and the reader follows the see:Also, gets RDF and and does smushing.
You cannot stop people from linking to huge "files" via rdfs:seeAlso,
be they in RDF or any other format, so any agent that blindly
retrieves all resources pointed to via rdfs:seeAlso will be in trouble.
I accept that it may make sense to discourage people to use
rdfs:seeAlso for non-RDF resources, but then the RDFS spec must be
corrected. Also, I think that an informally agreed FOAF practice is
not suitable for augmenting / refining an official W3C spec.
There may be clients out there that look for ".html" at the end of
URIs instead of checking the media type. Should we discourage people
to use cool URIs just for the sake of not breaking their code? I don't
think so.
We can push the community either way, but either we have to use
rdfs:seeAlso in that way or we have to push a lot of people
to change their fFOAF-generators and their FOAF-crawlers and their
LOD-client libraries to stop following those links.
As said, that may be a useful recommendation for the future, but it
requires, IMHO, to correct the RDFS spec and will still not guarantee
that you don't end up loading a PDF or image when following a
rdfs:seeAlso statement.
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.
Conceptually perfectly OK is one thing, of course. But that doesn't
give us practically perfectly OK.
This is a practical engineering exercise, building LOD protocols
which work.
A protocol that relies on perfect compliance with the specs is likely
very brittle.
After all, rdfs:seeAlso is not
rdfs:linkToASmallChunkOfVeryRelatedDateInRDF ;-)
The words in the URI of course have no semantics themselves, as you
know. They
are only mnemonics.
I think you understood what I meant. The RDFS spec does not state the
additional constraints that you put on the use of rdfs:seeAlso.
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.
This is the Linked Open Data list.
The Linked Data world is a well-defined bit of engineering.
It has co-opted the rdf:seeAlso semantics of "if you are looking up
x load y" from the much
earlier FOAF work. This protocol is heavily used in code and data
out there.
As I pointed out, at least Yahoo recommends using rdfs:seeAlso for
pointing to images. So we can agree that there is a problem, since
some usages of rdfs:seeAlso clash with the expectations / heuristics
of old code.
The URI space is full of empty space waiting for you to define terms
with whatever semantics you like for your own use.
I don't think this is a useful statement.
But one cant argue philosophically that for some reason
the URI rdfs:seeAlso should have some other meaning when people are
using it and
there have been specs.
I quoted the RDFS spec, and the old FOAF documents are IMO no
authoritative sources for the semantics of rdfs:seeAlso.
One *can* argue that the RDFS spec is definitive, and it is very
loose in its definition.
Yes, that is what I have been trying to do.
We could look at maybe asking for an erratum to the spec.
to make it clear and introduce the other term int the same spec.
But if the result is to make rdf:seeAlso the general term which
cannot be automated
then we have to be aware that there is a bunch of code to be changed.
I personally think that a client that does follow an rdfs:seeAlso
statement without checking the media type and/or resource size prior
to fetching and processing the data is suboptimal and should be
changed. No matter how the rdfs:seeAlso is is resolved, such clients
are likely to stumble.
Best
Martin
Tim
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
