Re: Semantics of rdfs:seeAlso (Was: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?)

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:fred@acme.org 
> ;   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
>>>
>>
>>
>
>

Received on Thursday, 13 January 2011 16:32:16 UTC