Seems like there is hard to gain consensus here. Would it be a good idea to create some sort of "best practice document" (RFC?) for how to "combine the Semantic Web with AtomPub" (I guess the title should be the first thing to change =).
If we first could succeed in creating such a document describing the current state-of-the-art, it would probably be easier to agree whether or not additions like Herbert proposed, would be a) backward compatible and/or b) add value ++ What do you think? - Erling On Thu, Sep 18, 2008 at 9:03 PM, Brian Smith <[EMAIL PROTECTED]> wrote: > > Peter Keane wrote: >> What about the case of a Media Link Enty? >> >> This from AtomPub spec 9.6: >> >> "The Media Link Entry contains the metadata and IRI of the (perhaps >> non-textual) Media Resource. The Media Link Entry thus makes >> the metadata about the Media Resource separately available >> for retrieval and alteration." >> >> Isn't this a specified case in which the atom elements are >> describing the media resource and not the entry? > > Either the relationships between the metadata, the content, and the entry is > ambiguous and application-dependent or the metadata has to describe the > entry. Those words from the AtomPub specification imply that the > relationships are ambiguous and so AtomPub has to clarify them for its > specific use of Atom. Following that, when you have an AtomPub MLE the > metadata describes the content, when you have inline content in an AtomPub > document the relationships are ambiguous, and when you are not using AtomPub > the relationships are ambiguous even with out-of-line content. That is, you > have basically the same problems as rel='about', but without the > explicitness of the rel='about' proposal (since you cannot easily tell > whether an entry is a media link entry or not in general). > > I don't think that is a very useful approach because it means we have to > write extra specification text to clarify what metadata applies to what > under what circumstances, we have to write code for each special case, and > we have to write more tests to verify that we handle all the specific > scenarios correctly. The conclusion is that Atom's metadata is meaningless > without additional application-specific clarification, so we cannot write > tools that interpret metadata uniformly across applications. That is > completely at odds with the goals of Atom. > > Instead, I prefer to think of AtomPub as a way of managing Atom entries > instead of a way of handling entries, media resources, and the media > metadata encoded as entries. Some of the entries might have out-of-line > content, and the protocol knows how to edit it, but the media resources are > always secondary to the entries. Thinking this way, there isn't a need to > have MLEs as a separate concept. Instead of regular entries vs. MLEs, we > have entries, some of which have "out-of-line content" while others have > inline content. This emphasizes that entries are all managed the same way, > that we should interpret entries' metadata uniformly, and that the entry is > the primary concept while the media resource is the secondary concept. This > fits with the way we manage media entries. An entry can exist without having > a media resource but a media resource cannot exist without a MLE. A media > resource is deleted when its MLE is deleted; the MLE isn't deleted when its > media resource is deleted (at least, that isn't required by the spec.). We > update app:edited whenever the entry changes; because the content is part of > the entry, whenever we update the content we have to update app:edited, > regardless of whether the content is inline or out-of-line. > > Examples 1: > > <entry ...> > <author><name>Brian</name></author> > <content src='something.html'/> > ... > </entry> > > Who is the author of the entry? Who is the author of something.html? Using > my way of thinking, Brian is the author of the entry and the author of the > content is unknown. Otherwise, everything is ambiguous; if the entry is part > of an AtomPub collection and the entry is a MLE then Brian is the author of > something.html and the author of the entry is unknown. But, if the entry > isn't a MLE entry then the authorship information is totally ambiguous. > > Example 2: > > <entry ...> > <id>urn:example:1</id> > <title>My brother's puppy</title> > <content src='http://example.org/puppy.jpg'/> > <app:edited>2008-01-01:01:01:01Z</app:edited> > <updated>2008-01-01:01:01:01Z</updated> > ... > </entry> > > <entry ...> > <id>urn:example:2</id> > <title>My puppy</title> > <content src='http://example.org/puppy.jpg'/> > <app:edited>2008-01-01:01:01:01Z</app:edited> > <updated>2008-01-01:01:01:01Z</updated> > ... > </entry> > > What is the title of the image? What is the title of entry urn:example:1? > What is the title of entry urn:example:2? Can an image have two different > titles at the same time? Using my way of thinking, each entry has the title > given and the title of the image is unspecified. Using the other way of > thinking, you have a mess. > > Bonus: Given an entry (in a feed or standalone), how can you determine if it > is an AtomPub MLE so that you know what disambiguation rules to apply when > interpreting the AtomPub text above literally. > >> I've struggled a bit in my own implementation with this exact >> issue, and wishing there was a switch that could be flipped >> to say "this is an MLE". I am not sure that in practice it >> matters all that much, since a specific use case will clearly >> suggest which you are talking about. I believe the challenge >> that Herbert is pointing to is that we need to be more >> precise is we are going to be deriving RDF from the Atom entry. > > That is why I eventually settled on the approach that I described in my last > few messages to this list. It is simultaneously 100% unambiguous and the > simplest thing that could possibly work. > > Regards, > Brian > > -- Med vennlig hilsen Erling Wegger Linde
