Re[2]: Fwd: Syndication model convergence and RDF


A quick disclaimer - the RDF vocabulary outputted by the stylesheet
was really just thought up ad-hoc. My intention was just to prove
whether Atom could be mapped completely to RDF, or whether there were
any holes in the spec that made a mapping ambiguous.

>> With the RSS1.0 model if you attempt to merge two documents you either
>> get a bit of a mess (multiple titles etc), or you have to do some
>> application level interpretation to select which instance of which
>> entry should be included in the output.

> Indeed, but it's also a bit of a mess carrying every historical
> instance

You don't have to unless you want to. It's perfectly fine to throw
away older instances as soon as you see them and not even store them
in your model, let alone carry them around. The advantage of an
instance-based model is that you can retain old entries if you want to
without needing two different models. The monotonicity thing works
both ways, if you don't state everything you know, that doesn't imply
that what you omitted isn't true.

> Personally I prefer it simpler - each entry as a single, eternal
> resource, with representation that may vary.

From a web point of view that is correct, but RDF doesn't describe
variable representations unless you do it explicitly (I think).

>> With separate "instance" resources, (which you would probably want to
>> tag with atomrdf:receivedDate or something), you don't have to remove
>> statements from the model, you are instead modelling a bunch of
>> statements, some of which are historic, and some of which are current.
>> If you aren't interested in the historic data, then you can just drop
>> it from the view. This seems to fit better with the monotonic RDF
>> model.

> But how well does it fit with the Atom model?

Well, the "Managing Feed State" chapter of the Atom spec is probably
relevant, but currently it is blank, but I'd say it is likely to be
either equivalent or a superset of the Atom model - which is better
than being a subset.

>> Note that there there is no collection construct that links feeds and
>> entries, but EntryInstances do have two links back to the feed (via
>> atomrdf:containingFeed and atomrdf:originFeed). So you can use those
>> links to get a big list of all entries ever in the feed. I prefer this
>> than using collection constructs, because both rdf:List and rdf:Seq
>> are essentially closed which doesn't seem right since feeds are more
>> like continuous streams.

> Heh, I think again there's a bit of overkill here, but I do reckon
> your avoidance of collections is probably a very good move. A simple
> containerish relation seems closer to the domain model.

atomrdf:originFeed is how head-in-entry is described.  I guess those
properties could be inverted to be "member" type properties.

> Order is another issue - personally I think it's clearer left out,
> or rather made explicit through dates or whatever.

Yeah, when it comes to merging two intersecting feed documents, then
you'd need an explicit date or something anyway.
 
>> b)
>> 
>> > <atomrdf:link>
>> > <atomrdf:Link>
>> 
>> > down to
>> 
>> > <atomrdf:link rdf:parseType="Resource">
>> 
>> Yeah, could do.  It loses the typed node though.  I know that the type
>> is implied by the RDFS, but I tend not to rely on RDFS inference.

> What we haven't really discussed is the intended applications for this
> - could make quite a difference in the approach... One question being
> whether a more concise treatment could be consistent with a more
> verbose, explicit & multi-instance per entry model. I dunno.

One useful application is that it would be a neat way to implement a
publishing server.  For a full implementation of a publishing server
it would need to store everything that was thrown at it, including
arbitrary extensions.  RDF could do that pretty well.

> How would you describe the kind of model implied by the output of
> your XSLT?

I'm not sure what you mean?

-- 
Dave

Received on Friday, 4 February 2005 08:03:31 UTC