how to express HTML in Turtle as a hypermedia type

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.

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

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.

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.

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

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

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

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

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.

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

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

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

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

Received on Thursday, 28 March 2013 02:28:28 UTC