Re: Links and graphs

hello graham.

On 2012-12-22 5:35 , Graham Klyne wrote:
> 1. RDF makes it relatively easy to create open-ended service
> descriptions in ways that one would not usually choose to attempt with
> "bare" XML.

actually, for service descriptions specifically, i wouldn't necessarily 
agree. a lot of design thinking in REST (which is how we are using our 
XML) goes into extensibility, because the main value for us is in 
allowing independent evolution. it still takes quite a bit of skill to 
create service models that can evolve within reasonable bounds, without 
leaving them so open that the service itself becomes an almost 
meaningless "do anything over here" service. to me, this is more of a 
SOA challenge than an XML one, and coming up with good models of how to 
do that is hard because it's a hard problem in itself.

> I also very recently discovered your "profile" draft
> (http://tools.ietf.org/html/draft-wilde-profile-link) which suggests to
> me a similar line of thinking.  (I recall you mentioned "profile"
> earlier in our discussion, but I didn't realize then that there was a
> specific proposal.)  A question this begs is the extent to which a
> profile attribution is necessary, or can be left implicit in the content
> - I can see possible advantages either way.

yes, this discussion was mentioned a bit when profile was discussed a 
while ago. if a podcast is a feed, why call it a podcast and not just 
treat it as a feed with some added features? that's a fair question, and 
my current thinking is:

- discoverability: it might be interesting for clients to know that a 
feed is a podcast, even though its current content contains no podcast 
content at all. the service makes explicit that clients should expect to 
see podcast things coming their way, at least potentially.

- client preferences: if clients can specifically ask for podcasts in 
their requests, servers may be able to content negotiate on the profile 
level as well, giving them podcasts instead of some alternative media 
feed format.

i am still a bit torn with RDF. if we use profiles in RDF, it's better 
than nothing, because at least some capabilities are exposed in the 
uniform interface. but essentially it would be the same as using 
application/xml for all XML-based services, something which over time 
has become an anti-pattern in the REST community, and i would say for 
good reasons. however, i do see that in the RDF community, there is a 
strong belief that media types should only be used for negotiating 
between RDF's various syntaxes, so maybe profiles are the best 
compromise that we can get to.

> I think there's a basis here we can use to progress our service
> description discussion:  I'm not claiming there aren't other ways to
> achieve what RDF achieves, but that of what's currently available, RDF
> lends itself particularly to an open-ended style of description.

yes, and that's a feature and a risk. open-ended for extensions is good, 
but when a client starts interacting with 10 different services, it 
still needs to decide which one it can interact with. web architecture 
has places in the uniform interface where that decision is supposed to 
be supported.

>> you're right that technically speaking, XML actually is not all that
>> relevant
>> anymore, pretty much every relevant "XML technology" out there today
>> is an
>> infoset or XDM technology, which are the two existing equivalents of
>> the RDF
>> abstract model.
> I agree that XML infoset serves the same purpose as the RDF abstract
> model, and that alternative surface syntaxes can yield the same
> underlying infoset.  Thus far, XML and RDF are similar as you say.  (I
> wouldn't say XML is "not relevant" - the infoset is clearly deeply
> rooted in XML qua syntax.)

yes, you're right. XML of course is very relevant. but start playing 
around with non-namespace-compliant XML these days, and you'll quickly 
see how pretty much every XML technology and tool out there stops 
working for you, because you're actually tied into a bigger stack than 
just XML itself.

> Some of the required outcomes of syntactic validation of XML can be
> achieved by semantic inference over RDF.  For example, one may need to
> test for sufficiency of information for a given purpose (such as a
> usable service description).  With XML, one often achieves this by
> imposing syntactic validity constraints.  With RDF one can use
> inference, coupled with a local closed world assumption,  which (if
> sound and complete) can tell whether sufficient information is present.
> Practically speaking, the effect is very similar, but the underlying
> mechanisms are somewhat different.

yes. RDF definitely has more machinery in place for you in these 
scenarios, and in XML you end up defining and implementing some of that 
by yourself.

> One consequence of the difference is that one can never use inference to
> decide that there is too much information present, which you can do with
> syntactic validation.

which makes it very hard to "filter" RDF in the firewall kind of sense. 
i think these kinds of capabilities would benefit RDF greatly, because 
any technology that wants to succeed in commercial IT on a large scale 
needs to allow people to efficiently declare and enforce policies. i do 
see that RDF does not *strictly need validation*, and that's kind of 
cool, but i still think that it would greatly benefit from having 
something like this, so that an RDF-based SOA would allow for better 
isolation of components.

> Maybe that's the difference:  with XML/XSD you'd have to type-annotate
> everything to end up with some comparable machinery.  With RDF, the
> machinery exists and becomes increasingly potent as additional type
> annotations are introduced.  Whether you see this as a difference in
> degree or fundamental nature is maybe a matter of taste?

probably. but i think we now do have established the fact that one way 
or the other, we can put the stacks next to each other and say they do 
similar things, even though maybe at different level of sophistication.

> I find the debate is interesting, and it makes me realize that while I
> see differences, they are maybe finer distinctions than I first
> assumed.  And I completely agree with your point of using established
> and successful patterns. (Indeed, that's really why I'm engaging in
> this, to better understand what those established patterns really are,
> and how they apply.  I think I've come on a fair way, and I don't think
> I'm proposing to discard anything that is already deployed and
> delivering value.)

i am very glad to read this. it is hard to have this debate without 
getting sidetracked, because there are so many interesting diversions 
along the way.

> A diversion.

;-)

> Since our earlier exchanges, I've come far more comfortable with NOT
> using Link: headers as an alternative to content-types.  Somewhere along
> the line, you mentioned late binding, and I think that's key, though I
> didn't immediately realize why - I just assumed that Link: headers could
> be dynamically generated too.

they can be, but the issue is that things that can be and should be 
expressed in existing places in HTTP shouldn't be pushed into Link headers.

> The example that has finally convinced me of your approach is
> considering a three-way scenario in which:
> 1. Client C requests a resource from S1
> 2. S1 provides a link to an information service (e.g. provenance)
> provided by S2
> 3. C then uses the service at S2
> I had been focusing on client-server coupling, in which one might regard
> information returned by a server as part of its content, using the Link:
> header relation type wasn't really increasing the coupling.  But what I
> initially overlooked was the coupling between S1 and S2:  like C, S1
> should only know that S2 has some resource, and not provide information
> about how to process it.

yes, that's correct. S2 can change what it serves at any time without S1 
knowing, so when S1 makes assumptions about S2 beyond the ability to 
just link to it, this increases coupling and thus may break over time.

thanks for the interesting conversation and happy holidays,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Sunday, 23 December 2012 17:13:21 UTC