W3C home > Mailing lists > Public > public-ldp@w3.org > March 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 26 Mar 2013 18:08:09 +0100
Cc: Erik Wilde <dret@berkeley.edu>, Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
Message-Id: <A46CE918-C4C1-4E47-BE7E-157E1E55EB68@bblfish.net>
To: Henry Story <henry.story@bblfish.net>

On 26 Mar 2013, at 18:03, Henry Story <henry.story@bblfish.net> wrote:

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

Sorry the text below was from http://www.rfc-editor.org/rfc/rfc2046.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/
> 

Social Web Architect
http://bblfish.net/



Received on Tuesday, 26 March 2013 17:08:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC