Problem with relationship feeds

[Ross Singer]

[Resending from February 6th, 2009]

Hi everybody,

So I've run into a bit of an issue with regards to feeds of resources
related to specific resources, such as:

http://demo.jangle.org/openbiblio/resources/4467/collections

These work fine as long as only one identifier if being requested...
it's pretty obvious what resource the collections are related to.

Where this falls down, however, is:

http://demo.jangle.org/openbiblio/actors/1346,1490/items

There is no indication of which items are associated with which actor.

I had sort of overlooked this problem because the only relationship I
ever did with multiple identifers was resources/{id,id,id,id}/items
and, when using the DLF Expanded format for Items resources
circumvents the problem because the Resources URI is in the metadata.

However, this is not something to depend on.

So, I think this is our first candidate for a 1.1 spec. Jangle
entries for relationship feeds need some <link> relationship back to
the identified resource they are related to.

Any comments on how this might be done?

-Ross.

[Ross Singer]

So I have a possible, easy and totally pure-Atom solution to this:

http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.link

For:
http://demo.jangle.org/openbiblio/actors/1346,1490/items

Each entry could have something like:
<feed>
...
<entry>
<id>http://demo.jangle.org/openbiblio/items/12345</id>
<link rel='via' href='http://demo.jangle.org/openbiblio/actors/
1346/items' />
...
</entry>
<entry>
<id>http://demo.jangle.org/openbiblio/items/12346</id>
<link rel='via' href='http://demo.jangle.org/openbiblio/actors/
1490/items' />
...
</entry>
</feed>

The 'via' relation is intended to specify a URI for the 'source' of
the entry. I think this keeps with the intention of both Atom and
Jangle, indeed the above URIs /are/ the source of the entry, since
this is, essentially, an aggregation of those sources. I see nothing
in the spec about the illegality of multiple via relations for the
same entry, which would come up for requests for many-to-one (or many-
to-many) relationships, like /items/{id},{id},{id}/resources where 2
or more items may be associated with the same resource.

If nobody has any objection with solution, I'll just start adding it
to the existing frameworks (since it's coming from Atom, not Jangle)
and we'll explicitly note this usage in the 1.1 spec.

Please weigh in with your comments or criticisms, I'd like to see some
sort of up or down on this by Code4lib.

Thanks!
-Ross.

[Ross Singer]

So don't everybody respond at once.

I just realized one thing that will prevent us from "just doing it".
Well, it can still be done, it's just uglier.

This relationship also needs to be sent by the connector, as well.
The Connector API spec allows it to send arbitrary link relationships
(as a hash) and for the meantime, this will probably be how we specify
this relation in 1.0-compliant connector/cores.

For 1.1, we probably want to figure out a more Jangle-y way to specify
these relationships, by adding another element to the data object.

My gut feeling is something like:

{
type:"feed",
data:[
{
id:"http://demo.jangle.org/items/12345",
association:["http://demo.jangle.org/resources/76543"],
...
}
...
}

But I'm by no means married to the word "association".

Comments welcome.

-Ross.

On Feb 17, 9:56 am, Ross Singer <rossfsin...@gmail.com> wrote:
> So I have a possible, easy and totally pure-Atom solution to this:
>

> http://www.atomenabled.org/developers/syndication/atom-format-spec.ph...

[Mike Rylander]

On Thu, Feb 19, 2009 at 11:51 AM, Ross Singer <rossf...@gmail.com> wrote:
>
> So don't everybody respond at once.
>
> I just realized one thing that will prevent us from "just doing it".
> Well, it can still be done, it's just uglier.
>
> This relationship also needs to be sent by the connector, as well.
> The Connector API spec allows it to send arbitrary link relationships
> (as a hash) and for the meantime, this will probably be how we specify
> this relation in 1.0-compliant connector/cores.
>
> For 1.1, we probably want to figure out a more Jangle-y way to specify
> these relationships, by adding another element to the data object.
>
> My gut feeling is something like:
>
> {
> type:"feed",
> data:[
> {
> id:"http://demo.jangle.org/items/12345",
> association:["http://demo.jangle.org/resources/76543"],
> ...
> }
> ...
> }
>
> But I'm by no means married to the word "association".

Since we're dealing with atom specifically, how about just using
"via"? That certainly explains the relationship, and is more explicit
than "association" ... eh?

(Also, that's an "up" from me.)

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com

[Ross Singer]

Thanks, Mike :)

That argument certainly works for me. On the flip side, the Connector
API is only mildly syntactically similar to Atom (the similarities are
more structural). The upside of this is that, should Atom fall out of
favor, the connector API shouldn't have to be completely rewritten (or
make no sense) to serialize sanely into some other format.

So, my question would be, does 'via' accurately describe the explicit
relationship between two resources outside the context of Atom?

If yes, then we have a winner.

If no, what's a good word token to define that?

What I'm saying is, to me it's a just a word. I don't care one way or
the other what word that is as long it pretty easily describes the
semantics of the element to someone new to Jangle.

-Ross.

[Mike Rylander]

On Thu, Feb 19, 2009 at 12:39 PM, Ross Singer <rossf...@gmail.com> wrote:
>
> Thanks, Mike :)
>
> That argument certainly works for me. On the flip side, the Connector
> API is only mildly syntactically similar to Atom (the similarities are
> more structural). The upside of this is that, should Atom fall out of
> favor, the connector API shouldn't have to be completely rewritten (or
> make no sense) to serialize sanely into some other format.

That makes sense.

>
> So, my question would be, does 'via' accurately describe the explicit
> relationship between two resources outside the context of Atom?
>

I think so, if we're talking about the connector being able to say
"you got here from there." If we're just trying to model
relationships in general, which I don't think we are (items will
already have some form of "I belong to resource X" field, yes) then
I'd prefer direction-specific, relationship-type-generic descriptor,
like has_a or has_many. "via" frees us from the "belongs to" type
stuff (which in a general sense implies too much hierarchy, IMO) while
still giving us a use-based tracing. Like referrer, but with just a
smidge more meaning.

IOW, I'd consider the choice of "via" to be a case of "atom got it
right, so let's just use that" with the happy side-effect of being a
direct mapping to the current implementation endpoint.

--miker

[Ross Singer]

This totally works for me.

I have no problem borrowing vocabulary from Atom where it makes sense
(I mean, we use 'title', 'content' and 'id', too).

So, this seems like a good candidate for 1.1?

For the throngs (throngs, I say) of you that are developing 1.0
connectors right now, the 'hack' of the connector sending the link
rel=via relationship should be both forward and backwards compatible.

{
type:'feed',
request:'http://demo.jangle.org/openbiblio/resources/1234,4321/items',
data:[
{
id:'http://demo.jangle.org/openbiblio/items/2345'
links:{
via:[
{
"type": "application/atom+xml",
"href": "http://demo.jangle.org/openbiblio/resources/1234"
}
]
}
]
}

So, what I'm saying is, nobody should feel they need to wait for 1.1
to implement this (assuming we agree this is the ideal way to
implement this in Atom).

Thanks,
-Ross.