Re: Fwd: Syndication model convergence and RDF

On Thu, 3 Feb 2005 22:02:05 +0000, David Powell <djpowell@djpowell.net> wrote:

> > I'm not really sure of the purpose of feedInstance either.
> 
> entryInstance is more useful than feedInstance, but it is essentially
> there to decouple the changable feed metadata from the fixed feed URI
> - see below...
> 
> > Why not collapse e.g.  (random chunk):
> 
> a)
> 
> > <atomrdf:Feed rdf:about="http://example.org/feed">
> > <atomrdf:feedInstance>
> > <atomrdf:FeedInstance>
> 
> > down to...
> 
> > <atomrdf:Feed rdf:about="http://example.org/feed">
> 
> I introduced FeedInstance and EntryInstance because feeds and entries
> are expected to change. If you detach each instance from the concept
> identified by the id, then you can merge two feed documents without
> any unintended smushing.

Ok, this does seem one reasonable approach - I believe Henry derived a
similar versioned model at one point as well.

> 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, which doesn't really reflect the typical application model
all that accurately either. I dread to think what happens with the
multiple-instance feed when such instances are passed into aggregated
feeds and republished... Personally I prefer it simpler - each entry
as a single, eternal resource, with representation that may vary. I
suspect that'll be closer to the way the Atom spec will describe
things too (whether or not that's a good thing is yet another
question...).

Having said that it should be possible to have multiple projections of
the same information in forms that will be consistent within each
other in RDF/OWL. (Hopefully ;-)

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

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

Just out of curiosity - the 0.3 Atom/OWL I had a go at attempted (not
all that successfully) to be spec-faithful and was fairly
similar-syntax instancewise (largely because RSS 1.0 did it). Henry's
latest mapping is along similar lines, although he's been through some
very object-oriented mapping on the way. How would you describe the
kind of model implied by the output of your XSLT?

Cheers,
Danny. 


-- 

http://dannyayers.com

Received on Thursday, 3 February 2005 23:47:40 UTC