Related entries and feeds: links and link expansion

BioSensorAB » Related entries and feeds: links and link expansion

BioSensorAB » Related entries and feeds: links and link expansion — Tue, 19 Feb 2008 09:50:43 GMT

PingBack from http://www.biosensorab.org/2008/02/19/related-entries-and-feeds-links-and-link-expansion/

re: Related entries and feeds: links and link expansion

Andy — Tue, 19 Feb 2008 13:17:47 GMT

Yes, using the Link element seems more descriptive and true to the spirit of Atom than a custom element like <gd:entryLink/> in GData. Interestingly for interop the GData approach uses the same number of nested elements for a child Entry or Feed as the MS approach above.

re: Related entries and feeds: links and link expansion

juliel — Thu, 21 Feb 2008 06:32:43 GMT

I was thinking about how to do this (drill into collections dynamically) when I was playing around with Astoria in Popfly. If I understand this correctly, it will really open things up nicely. I'm not really worried about ATOM conformance, so I'll let you guys work that part out! :-)

Julie

Astoria Team ponders adding expansion links into the response data

Hot Topics — Fri, 22 Feb 2008 01:14:37 GMT

Pablo Castro explains the reasoning behind wanting to add links to the Astoria payload so that it's

re: Related entries and feeds: links and link expansion

Danny — Fri, 29 Feb 2008 22:02:25 GMT

Oh Pablo, I don't know whether to laugh or cry: RDF gets dropped and then right away you need a hack to type links (i.e. do RDF properties)..?

Anyhow, just as a side fyi, you might want to take a look at <a href="http://www.w3.org/TR/grddl-primer/">GRDDL</a>, it offers a way of automatically extracting RDF from arbitrary XML (main mechanism is XSLT, but it's pretty clever how it gets invoked). Probably not immediately useful in this context, but might spawn some ideas.

re: Related entries and feeds: links and link expansion

Danny — Fri, 29 Feb 2008 22:45:38 GMT

PS. Just remembered - atom:link@rel supports URIs - why not give the relation a URI? rel="related" does seem a bit redundant.

re: Related entries and feeds: links and link expansion

pabloc — Fri, 29 Feb 2008 22:55:08 GMT

Hey Danny,

Thanks for the pointer, I'll read on the GRDDL stuff.

Re: links...yeah, I agree, rel="related" is not exactly adding information there. Probably a URI with a predictable form (to know what relationship it is) is the best choice.

-pablo

re: Related entries and feeds: links and link expansion

Mike — Wed, 05 Mar 2008 20:10:01 GMT

I agree that using the Link element is a natural and understandable way to go. But to make the expand functionality complete and usable you must be able to filter on properties of the nested entities. So, something like

Customer?$expand=SalesOrderHeader & $filter=SalesOrderHeader/TotalDue gt 1000.0

Should be possible.

re: Related entries and feeds: links and link expansion

Steve Ickman — Fri, 21 Mar 2008 19:14:48 GMT

I second (or third :) the use of a URI for atom:link@rel. I known what you guys are striving for with the generic "related" rel type but the client already has to understand the schema of an "event" entry to do anything useful with it and to do the $expand thing they even have to know up front that events have related Venu & Attendees resources. So strongly typing the rel value seems like the more consisten thing to do.

-steve

re: Related entries and feeds: links and link expansion

Joe Gregorio — Wed, 04 Jun 2008 16:58:06 GMT

With respect to the expanding links inline, at Google we are considering using the atom:content element inside the atom:link element. The meaning of atom:content is already specified, and given the discussion on atom-syntax the consensus appears to be that atom:content appearing as a child of atom:link would qualify it as foreign markup and thus be valid.

re: Related entries and feeds: links and link expansion

Alistair Miles — Mon, 16 Nov 2009 12:01:47 GMT

Hi, I see this discussion is a bit old now, but FWIW we're using Atom in a project to develop a system for managing data and metadata for malaria research, and have hit some similar questions.

In particular, I have been wondering if it was reasonable to expand related entries inline, and if so, what is best practice for doing so, so it is a relief to see others have considered doing something similar. Personally, I think it makes good sense, and the only question is, what element should you use as the direct child of the link element to contain the inline entry? We had tentatively plumped for stickiing the expanded atom:entry directly in the atom:link element, although this looks like it would violate the atom format spec, but it just seemed unnecessary to use some intermediate (like m:inline as you've done). I don't really mind using an intermediate, but if it is necessary it would be nice to have some consensus on what best practice is - I see Joe Gregorio has suggested using atom:content, although (without delving any deeper) I'm a bit confused as to why an atom:content element can be treated as foreign markup - the content model for atom:link is undefinedContent = (text|anyForeignElement)*, and anyForeignElement seems to exclude anything in the atom namespace.

The other two questions we had were (1) how should we represent different types of link relationships, and (2) where should we stick the foreign markup that is our data?

For (1) we chose to use rel attribute values, because this seemed to correspond to usage of rel attributes in HTML. We chose to use plain strings as rel attribute values (e.g. "chassis.study") but thought of using URIs as per Danny's suggestion. We haven't gone for URIs yet because we have no compelling reason for it, but would be happy to shift if there was a good reason.

For (2) we've stuck the foreign markup in the atom:content element with type application/xml as you've done, which seemed the natural place to put it from reading the atom specs, and because it keeps the distinction between data and metadata a bit clearer, however were concerned that google's data APIs don't bother and stick the foreign markup directly within the atom:entry element. Maybe it doesn't matter, but it would be nice to have some guidance / consensus on this.

I'd be grateful to hear any comments or followup on where you've gone with these issues.

Cheers,

Alistair