Re: how to express HTML in Turtle as a hypermedia type

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

> hello henry.
> 
> On 2013-03-27 1:28 , Henry Story wrote:
>> 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.
> 
> certainly one can, it's just that it hasn't been tackled so far. that's the hyperRDF meme i've been using.

yes, it's another word for linked data ( hyperdata ) and it is what this group is working on.  

> 
>> 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.
> 
> i'd say there are three different ways you find, generally speaking, types links in XML these days:
> 
> 1: specific link vocabulary: <form action="" .../> is a good example for a specific link in a vocabulary. the interaction is non-trivial (requiring packaging rules to be implemented that tell you how to submit for fields and either sent a GET/POST). <img src=""/> is the same, but much simpler. here the interaction is retrieval, the assumption is to GET some image/* representation.

Yes, just write out a vocabulary that describes an html form. It's not very difficult to do. Mark Baker
did it with RDF Forms:

 http://www.markbaker.ca/2003/05/RDF-Forms/

Getting wide adoption is the bigger problem. 

> 
> 2: generic link vocabulary and standardized link relation: <link rel="about" href=""/> is a pattern in a variety of XML vocabularies (JSON sometimes uses something similar). in this case, "about" must be IANA-registered, and in the registry you can find the description (not RDF, in most/all cases, just text) what it means.

yes, in atom-owl we have XSLTs for translating atom into Turtle.
http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html

  http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#sec-example

Perhaps you would disagree with the modelling of the link relation and would rather it be 
an xsd:anyURI . In that case you could model it like this:

<entry> :link [ a :Link;
                   :rel "http://www.iana.org/assignments/relation/alternate"^^xsd:anyURI ;
                   :to [ :src <http://example.org/2003/12/13/atom03>;]
              ].

Or one could argue the above logically implies this simpler triple:

  <entry> iana:alternate <http://example.org/2003/12/13/atom03> 


> 
> 2: generic link vocabulary and standardized link relation: <link rel="http://dret.net/link/42" href=""/> is using the pattern of 2, but uses a URI instead of a registered link relation. if you know what link relation http://dret.net/link/42 identifies (it's an identifier, not a link!), then you know what the link means. if you don't know what link relation http://dret.net/link/42 identifies, then you're out of luck.
> 
> as a best practice, in the last case hopefully http://dret.net/link/42 would resolve to something useful, probably a documentation web page explaining what the link relation means. but that's optional.

See above.

> afaict, these are the patterns how link appear in today's web, and they are actually pretty consistent across HTML, XML, and even JSON (to some extent, JSON does not have just such a natural model to represent this). but even for JSON, typed links matter, because JSON wants to take advantage of IANA's registry as well. http://tools.ietf.org/html/draft-nottingham-json-home-02#section-3 shows a format (under development) that exposes link relation types (the can be registered or not).

Yes, it's not a big problem as explained: use an xsd:anyURI format or use a urn.

> 
>> 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!
> 
> you don't have to register a mime type, there are naming conventions so that you can just roll your own.

Theoretically. But mime types are not URIs, there'd be no way of finding out what the meaning of one is.
So you can't practically roll your own.

> but yes, there are countless numbers of ways how parties can interact, following interaction protocols, and all of these need to be identified. my guess is that the identification need for these interaction protocols will not simply disappear in RDF, it just seems that people want to push it into profiles (some HTTP visibility), or embed it in RDF itself (no HTTP visibility). that's an engineering decision with side effects, but the fact that there can be an infinite number of ways how to buy something remains.

That's why the mime type is not the right place to put this information. 

> 
>> 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.
> 
> can you write me turtle that describes completely to a client how it has to implement HTML form submissions? i think (correct me if i am wrong) that your claim is that i can describe everything about a media type that needs to be know in RDF. assume i want to write a media type that defines the exact same submission rules for form fields that HTML defines, including the dance around GET/POST and multi-part submissions for file uploads and so forth. if you can write RDF that does that, and show me a generic RDF client with no knowledge of HTML than then is able to do everything that an HTML needs to do, then i rest my case.

See Mark Baker's proposal.

But the LDPC's we are building here are just another such way of doing things: you can POST a complex Turtle Description
and as a result you create a new resource. In fact it is much more powerful than html forms.

> 
>>> 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" )
> 
> i knew you would sort of like that ;-) my issue with this is that it may be able to describe the interaction mechanics (but even then i challenge you to cover the HTML form submission case i just mentioned), but it doesn't cover the interaction semantics (i guess you refer to those as pragmatics). while for simple cases i might be able to say that "POST this kind of thing over here", it's very hard to imagine how to say "oh and btw, everytime you do this, we log all your data and publish and sell all of it and your consent is implied." again, show me RDF that would describe this and let a generic RDF client act in the way that i would act if i read this disclamier: i might think twice before starting to interact with that service.

It would be easy to write something like a rights vocabulary in RDF. Creative Commons does it. The problem is not the expressive power of RDF, the real problem is getting the lawyers from around the world to work out how to create a
simple ontology that every human being can understand and that can have world wide application.

> 
> but regardless of whether RDF can fully/completely describe everything that matters for a service or not, it definitely at least can make links discoverable, and tell me which interactions i am going to engage in. this is what i would expect from hyperRDF. i would also expect that for many services, i would still need a client to have some built-in knowledge about the service, so that it could make certain decisions smartly.

It is just a question of identifying the needs. We can then write the vocab for it.

> 
>>> 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.
> 
> people are welcome to not follow the rules of a media type. that's not my responsibility. but when we, for example use a profile="" attribute in our XML schemas, the media type clearly says" this is an identifier. it's not a link. don't expect this to resolve to anything at all, or anything useful.

yes, so in RDF we can use "http://some.example/ont"^^xsd:anyURI to do that. Or just use a urn that does not have
a resolution mechanism. That seems like the obvious way to go.

> for our media type, the semantics are: see if you know a profile, and then you can infer something about additional constraints. the only operation defined for the profile URI is string comparison. of course people will paste the URI in a browser and hope to find something useful, and we try to give that to them. but if they write clients doing this, and then the clients break, because the profile URI doesn't respond, it's a client error (btw, all of this just mirrors exactly how profiles are defined and used in HTML).

yes, these are the kinds of discussions that people in the REST space can waste their lives and their
employers money on because they don't have clear semantic tools to help them make the distinctions, and
so they have to keep re-inventing the same answers mime type by mime type. 

Instead of re-inventing this problem for each new format and each new mime type for that format,
in RDF we have three options:

 1. Use a derferenceable uri (http, https, ftp,...) scheme as a reference <http://...> 
   when the terms is one describing a resource, that furthermore can be fetched.
 2. Use an "..."^^xsd:anyURI literal if you need to use URIs in the form of (1) and don't want them to 
     be dereferenced
 3. Use a URN if you don't want the interaction semantics.

You may want more, but that's enought to do all the work that needs doing in this space.
Perhaps we should add this to the Best Practices guide.
 
> 
>> 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?
> 
> you can and you should if you want to. but ultimately, HATEOAS has the goal of driving application state by following links, so i am telling you which links to follow to get your job done. if you want to fool around and try others by simply following any URI, be my guest. you might even find interesting new things along the way, and that's good, too. just don't expect to get the job done that my service has been designed for.

Browsing the web is "fooling around". That tells more about the Web2.0 state of mind than anything else could!

> 
>>> 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.
> 
> just repeating my challenge here: write me turtle that teaches a generic RDF client HTML, specifically all form submission rules.

Done above. Now, I am not going to spend all my time answering your challenges, of which you could invent
and infinte number. I think next it will be up to you to proove that things cannot be done. But
really why not move on to a more interesting topic. 

> 
>>> 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"
> 
> as you wish. i am really curious about this.
> 
> cheers,
> 
> dret.

Social Web Architect
http://bblfish.net/