On Fri, 7 Jan 2005 19:45:43 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
Given Henry's proposal, the person that uses RSS 2.0 today would
notice no additional complexity. The only people that would need to
know a little about RDF would be those that wish to develop
extensions. All they would
At 6:31 PM +1100 1/7/05, Eric Scheid wrote:
Aside from focusing on the publishing protocol, which is well due, what else
happens after we finalise the format spec?
Specifically, what are the IETF hoops that need to be jumped through, and
what periods of diligence/comment are mandated? Or will the
In
addition to being cumbersome, there is no good way to show that the
photos all go together.
Ray: There are several, IMO.
(1) Put them all in the same rss:category.
(2) Use ENT and assign them all at least one common topic.
(3) Put them in a distict feed.
At least one of those is fairly
RSS 2.0 DOES have a one enclosure per entry restriction, so we're
breaking RSS2 compatibility. Why wouldn't multiple enclosures be
multiple posts?
On Friday, January 7, 2005, at 01:32 PM, Danny Ayers wrote:
If I propose an extension,
e.g. embargoDate, and I want anyone to use it, then I'm going to have
to specify how it works. E.g. prism:embargoDate can appear as a
child of atom:entry and it gives the embargo date for the entry...
...
On Friday, January 7, 2005, at 01:59 PM, David Jacobs wrote:
RSS 2.0 DOES have a one enclosure per entry restriction, so we're
breaking RSS2 compatibility. Why wouldn't multiple enclosures be
multiple posts?
Multiple enclosures per entry would make it impossible to translate
some Atom feeds to
I'm not sure why this discussion has popped up again, but it seems to me
that there will always be people who only can grasp the bits and bytes
that actually go across the wire, and there will be several sets of
people who can only grasp the higher level abstractions that they see
through the
I'd say that the most useful basic features of RDF are:
1) Property names are namespaced for extensibility.
2) Important entities can be assigned global identifiers so that they
can be referred to externally.
3) Statements are properties of an object rather than being simple
name/value
Friday, January 7, 2005, 9:28:33 PM, you wrote:
Another example might be a property such as ex:rating, intended to
provide slashdot-style ratings specific to the community of readers of
that feed. If those entries are republished, then the original ratings
shouldn't be republished in the
On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy [EMAIL PROTECTED] wrote:
Could you give an example of something useful that a real world
application would be enabled to do?
Off the top of my head, how about categorizing entries by their properties.
But being able to mix extensions in a
Sam Ruby wrote:
I'm not sure why this discussion has popped up again...
In the case of RDF, there exists a standard means to associate a
document with a mapping. This standard is called GRDDL. [1]
Meanwhile, it would not be harmful to mention this one element or
attribute (anybody have a
Would you be satisfied with a paragraph that says that those who extend
Atom may do so by putting in namespaced elements, and that such
elements, when the information they contain is relevant to an entry,
SHOULD appear as a child of atom:entry?
Tim: +1, for the sake of compromise if nothing
On Jan 7, 2005, at 2:38 PM, David Powell wrote:
I think if we ensure that these properties apply to the Atom model,
then it will be beneficial to Atom, and will make any mapping between
Atom and RDF a lot simpler.
Please propose specific edits to current drafts for the WG's
consideration. -Tim
Let me see if I can correctly restate the following in language I'm
familiar with--let me know whether I've got this right or not:
On Friday, January 7, 2005, at 03:38 PM, David Powell wrote:
I'd say that the most useful basic features of RDF are:
1) Property names are namespaced for
14 matches
Mail list logo
