Re: Section 4: LDPR/non-LDPR formal definitions

On 26 Mar 2013, at 17:25, Erik Wilde <dret@berkeley.edu> wrote:

> hello henry.
> 
> On 2013-03-26 7:56 , Henry Story wrote:
>> On Safari, Chrome and Netscape it shows it as plain text. That is it does no interpretation
>> whatsoever more than converting them to ascii strings and displaying them as such. This
>> is indeed the correct behavior. You get as a user to see the "<html>..." characters as posted.
> 
> it's not converted to ASCII, it is simply displayed in the character set that is signaled in HTTP. the server says it's sending plain text, the client treats it as plain text. end of story.

Bytes are sent over the wire. Bytes are not ASCII. ASCII is itself an interpretation of the bytes.
As I did not specify the character encoding on the server for this file
 http://bblfish.net/tmp/2013/03/26/htmlServedAsText.html
it is indeed decoded as ASCII.

http://www.rfc-editor.org/rfc/rfc5147.txt

[[
   A critical parameter that may be specified in the Content-Type field
   for "text/plain" data is the character set.  This is specified with a
   "charset" parameter, as in:

     Content-type: text/plain; charset=iso-8859-1

   Unlike some other parameter values, the values of the charset
   parameter are NOT case sensitive.  The default character set, which
   must be assumed in the absence of a charset parameter, is US-ASCII.
]]




> 
>> So as you see when you post HTML it can show you links even if they are broken. Changing the
>> mime type just changes the interpretation of the bytes.

This was part of a longer discussion with Kingsley. The larger context is missing here.
I was pointing out 2 things:

  1. you can publish html with text/html content type that has links that do not go anywhere, and the
    browser will show those links interpreted properly with underlined hyperlinks
  2. If you change the mime type to text/plain you only get the ascii, not an interpreted HTML.

> 
> what do you mean by "show links"? you mean because you as a reader of plain text know HTML, you can parse it and then recognize the links? instead think of me showing this plain text to my mom. she might spot some words and read them out aloud, and would simply have no idea about the whole markup stuff and would say "and then there are a lot of weird characters in there". she'd never get to identifying links because she (unlike you) doesn't parse HTML in her head very well. so it doesn't matter whether the links *in the HTML* were broken or working, when you serve HTML as plain text you just have no idea where they are (or what links are in the first place).

that is indeed what I was saying. text/plain interpretes the bytes purely as characters ( in the 
example I gave those were interpreted as ascii ). There is no further parsing done thereafter by
the user agent. A human who knows how to parse it could. Your grandmother probably has better things
to do than to learn how to parse html, and she is quite right not to bother learning that skill.

> same for hyperRDF: when you see RDF, you see many URIs. some of them are just identifiers, never meant to be dereferenced (which is perfectly fine in RDF).

If you want to use URIs that are not meant to be dereferenced use URNs. Those cannot be dereferenced. If you 
use URLs you are implying its dereferenceability, especially in the context of RDF where the URIs are use as
referents as in <http://bblfish.net/people/henry/card#me> ie between <>. If you don't want to use those use
xsd:anyURI literals.


> some may be dereferencable, but you don't know which, and you don't know the service semantics of doing so.

That is not anymore the status quo in RDF land. As Richard just pointed out, the spec defining 
RDF graphs says, when explaining what the IRIs in an RDF graph mean  (http://www.w3.org/TR/rdf11-concepts/#referents )

[[
Perhaps the most important characterisitic of IRIs in web architecture is that they can be dereferenced, and hence serve as starting points for interactions with a remote server. This specification, however, is not concerned with such interactions. It does not define an interaction model.
]]

This was of course always the intention of RDF. But clearly it was felt to need clarification in the
recent spec.

> some may require specific interactions, such as "when you find a 'self-destruct' link, follow it with a DELETE method, and the server will self-destruct."

You cannot tell what the meaning of a URI is by looking at it. You find it as part of a graph, that is in relation
to other URIs. RDF stands for Resource Description Framework. So if you want to say that a URI is one that when 
using a non-nullipotent method ( ie anything that is not GET or HEAD ) does something special you can/SHOULD
describe what it is that it will do, preferably using RDF. For example a triple such as 

<http://remote.com/resource/> a ldp:Container .

Will tell you what types of things you can do with that resource.

> you have no idea what the link semantics are unless you know the service, and just following links blindly only because you saw a URI and maybe even found an annotation hinting that this URI should be dereferenced using DELETE (without knowing the pragmatics, as you correctly pointed out), may lead to surprising results (such as self-destructing servers).

It is not surprising that non-nullipotent methods result in side effects. 

As with anything you discover what resources can do by looking at descriptions of them. You can describe my resources and allow people reading your resources to arrive at my resources. But in the end my resources SHOULD be the ones that are
responsible for giving information about how to interact with them non-indempotently. 

To do this they need to be able to describe themselves. What better way than to use a Resource Description Framework
to do so?

Henry

> 
> cheers,
> 
> dret.

Social Web Architect
http://bblfish.net/

Attachments

Received on Tuesday, 26 March 2013 17:04:29 UTC