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

On 27 Mar 2013, at 02:21, Erik Wilde <dret@berkeley.edu> wrote:

> hello henry.
> 
> On 2013-03-26 15:09 , Henry Story wrote:
>>> but that's pretty much exactly what henry was linking to in the RDF 1.1 spec. it vaguely hints at a possibility, does not say how to interact (probably assuming you just try a GET), and is read-only.
>> I'd love to know how you think that adding a new mime type to Turtle would help you
>> work out wether a resource should not just be GETable but also perhaps POSTable, or
>> DELETEable, etc... How is this trick going to work?
> 
> i am glad you asked. it depends on whether you want to define a generic hypermedia format (what i refer to as hyperRDF), or a specific one (our LDP). in every hypermedia format, links have defined semantics. for example, in a generic hypermedia format, you may just have a mechanism to encode link relation types (link/@rel is a typical XML pattern for that), and then the link relation type need to say how it is supposed to be used. a generic hypermedia format supports typed links, and the types then define how to interact. that is usually done in service documentation for the formats using generic formats, so that a link relation type is documented as a client knows "when i POST the format of an order that lists products, that means i am placing that order and the good will be delivered." in this style, the media type identifies the generic type that exposes links and their types, and the application using that format is often identified somehow, maybe profiles are a promising candidate here.

Ah that is nice. As it happens RDF supports typed links too: we call them relations. 
We can also type these relations. It is completely possible to create link types that
allow one to make decisions about how to use the resource linked to. Certainly if one
can do it in XML, one can do it in RDF, and hence in Turtle. 

Perhaps the best is if you give us one typed XML link relation, and we see if we can
express this in RDF. Then you can tell us what is missing in the translation.

> 
> specific mime types can be even more direct and could define a mime type for a shopping service, and then define an <order/> element that would contain the link to the ordering service. or whatever else you want to do to expose ordering capabilities.
> 
> in both cases, the mime type allows clients to understand the fact that they are interacting based on representations that contain links, and the mime type allows them to find out which links count.
> 
> this is important, because for example the product pages could also contain URIs as product identifiers, and clients would need to use those product identifiers when composing an order. however, in the context of the service these URIs are not links; clients are not supposed to follow them, and if they do, the leave the ordering service (and may just run into 404s). so the mime type makes it possible for clients to understand which URIs have hypermedia meaning (the REST hyperlinks guiding the clients through the ordering process), and which one don't.
> 
> without a hypermedia mime type guiding them, clients wouldn't know the difference between URIs that are links, and ones that aren't.

Wow. So we are going to have an explosion of different mime types in this scenario. One for a shopping application, one for an ordering application, one for a book browsing application, one for a tweet application, etc.... etc... Managing mime types is going to be more complex it seems that managing RDF vocabularies, and we'll have to go through a centralised standards body to get them accepted on top of it! 

> 
>>> calling the above "may statement" hypermedia basics is a very optimistic view of the world. keep in mind that not all URIs in RDF are hypermedia links.
>> So adding a new mime type is going to help solve this problem how? You'd still have RDF but now somehow it would be obvious that URNs would not be dereferenceable?
> 
> of course i never proposed to just mint a new media type and do nothing else. it would need to be one that turns RDF into a hypermedia format, probably by adding annotations that allow services to be specific about which links are part of the hypermedia flow.

Why do you keep thinking this has to be done at the syntax level and not at the semantic level? 
RDF Describes resources. Why cannot we not describe what kinds of interactions one can have with
resources? If you think this cannot be done in Turtle please give us a simple example of what cannot
be done.

> 
> i have to admit that i am not a fan of this particular approach of doing this, but http://www.ws-rest.org/2012/proc/a5-9-verborgh.pdf is going in the right direction, it might be interesting for you.

This article is suggesting one use N3 rules to describe how to interact with resources. One could
use SPARQL which would be at least a formal standard. In any case they shows how you can 
describe POST/PUT/... interactions in Turtle. They even suggest using RDF as a hypermedia
format. ( See the section "Dereference link types" ) 


>> Btw, perhaps you'd care to elaborate on "not all URIs in RDF are hypermedia links". Can you give us a few examples?
> 
> for example all the ones using non-dereferencable URI schemes.

So an example would be 

  <urn:ietf:rfc:2648> a foaf:Document .

So what is the problem? I could put such a URI in a HTML <a href="urn:ietf:rfc:2648">RFC 2468</a> and would
have the same effect in HTML. A browser could use a plugin for such urns and find me the right RFC. Most 
don't. It is the type of the URI here that dictates what interactions it supports. An RFC urn does not support
GET/PUT/POST/DELETE....

> and in the context of specific services all the ones that are not part of that service. if i want to learn how to accomplish a certain goal using a REST service, which are the URIs i need to interact with? these are the ones that are hypermedia links for that service, the other ones aren't.

So how would you write this out in your favorite XML format? You could make restrictions I suppose to 
only relative URLs to restrict to part of the service in whatever format you come up with. But that
is probably going to still allow people to use your format to reach outside of your service, or to 
point to non existing resources.

It is odd to have an afficionado of hyper text be so worried about links to other services. Why 
could I not point to your LDPC from my service?

> 
>>> if your format uses URIs as identifiers, but provides no way to distinguish identifiers from hypermedia affordances, i wouldn't really call it a hypermedia format.
>> What is a hypermedia affordance?
> 
> every link i can follow that has application semantics defined by the media type. if i follow an img/@src link, i get an image. that's a useful thing if i want to render a web page. if a web page has a head/@profile, HTML specifically says that this URI is not supposed to be dereferencable, so it's an identifier and not an affordance (in the context of the HTML media type, of course, which doesn't mean that there *could* be something/anything at that URI).

In html 401 this is not what is written. It says that a profile URI can be used in two ways the second of which:
http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3
[[
As a link. User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). This specification does not define formats for profiles.
]]

Anyway, assuming your example stood up...

Turtle has semantics that are defined by its media type.
You can use it to describe things on the web.
The RDF semantic spec makes clear the distinction of when you are talking about a thing and when you
are talking about a URI, so we can distinguish a "hypermedia affordance" from a URI. Here is an example

  <http://tools.ietf.org/html/rfc3986> a foaf:Document ;
         foaf:title "Uniform Resource Identifier (URI): Generic Syntax" .

Says something about RFC 3986. If you wanted to use a URI and make sure you
were not saying something about the thing the Uniform Resource Identifier was
identifying (  the resource ) then you could do this

<> html:profile "http://www.acme.com/profiles/core"^^xsd:anyURI .

But really my guess is that in Turtle we'd just think of these as @prefixes , 
ie namespace declarations.

> 
>> So you are saying we need perhaps a whole new semantics. Have you read the RDF semantics carefully?
>>     http://www.w3.org/TR/rdf-mt/
>> Is your project that we need something like this but a hypermedia version? That seems like a huge task
>> and perhaps a bit out of scope for this working group.
> 
> yes, it is. that's what i am hoping for for hyperRDF, but i know that this is not something LDP can wait for. but since RDF is not hypermedia, we need to make up for this, and be explicit which links in the RDF we expose are driving application state (a la REST), and which ones don't (because they are not part of the LDP interaction model).

Look I have good news for you. You don't need to start another 10 year effor to build a better
semantics. You have it. It's just that you need to learn how to use it.

> 
>> Or is it that you think that just adding a new mime type profile is enough to do the whole semantic
>> heavy lifting? That would indeed by an amazing feat. In one simple stroke of a pen we'd make all
>> these logicians useless.
> 
> no, but i don't think i ever said that all we need is a mime type. all i am saying is that we need to be a hypermedia media type.

That's what Turtle is. I have not seen any arguments on your side that stand up to scrutiny to show
that it is not. If you could come up with a simple example (preferrably well known and deployed) 
in your XML format of choice then we could see what is missing in Turtle. Perhaps open a new thread 
for this: "how to express xxx in Turtle as a  hypermedia" 


> 
> cheers,
> 
> dret.

Social Web Architect
http://bblfish.net/