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

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.

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.

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

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.

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

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

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

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

cheers,

dret.

Received on Wednesday, 27 March 2013 01:22:06 UTC