Ken MacLeod wrote:
>
> I want to quickly repeat something I think Seth said, or he at least
> implied: There are existing taxonomies that do not lend themselves
> well to creating "topic URIs". We also would have no way of
> automatically creating such topic URIs outside of a
> taxonomy-by-taxonomy basis.
>
> I don't see this as a major roadblock, going back to Eric's prose
> description of the model:
>
> > in a most general case we need to associate 3 things with a
> > dc:subject categorizing a channel or an item:
> >
> > 1) A human readable text (keyword).
> > 2) A topic (external resource identified by a URI).
> > 3) A topic system (external resource identified by a URI).
>
> I don't see any reason an existing taxonomy couldn't just be
> represented by a "topic system URI" (the URI of the taxonomy) and
> "human readable text" (a topic within that taxonomy system).
I think we should see URIs are names, not (only) addresses.
This is central to RDF (and extended XLinks and topic maps, ...), see
for instance Tim Berners-Lee presentation for XML World [1].
The right way to identify something is using a URI, not using a
combination of URI + "human readable text".
Why couldn't we include both as optional in the model and let the
taxonomy authors decide which they want to use ?
Eric
[1] http://www.w3.org/2000/Talks/0906-xmlweb-tbl/Overview.html
> -- Ken
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Seth Russell <seth@...> wrote:
> When language works, it works because each of us uses the same word for the
> same thing. So the semantic web is trying to make its language work by using
> the same URI for the same thing.
>
> *** But if we use different URIs for the same thing, it doesn't work! ***
Hmm, let's try replacing URI with word, as you've implied above:
*** But if we use different words for the same thing, it doesn't work! ***
Have you looked at a thesaurus recently? ;-)
Anyway, the point is, that it's perfectly OK to have multiple words (or
URIs, as the case may be) that represent a subject. They all have slightly
different meanings, but one can say (or make an RDF assertion) that they're
all similar, or represent the same thing.
Now for a specific example:
> But if everybody makes up their own URI for WAP it will be just wasted energy.
> I will just end up with a <rdf:Bag> of different URIs; and when MyMemory
> writes RDF to others about WAP it will not know which one to output.
The easiest solution would be for it to output it's own:
http://RobustAi.net/MyKB/seth@robustai.net/topics/WAP/
However, you do have a valid point, one which I've recently made at the
W3C's URI list:
"With the increasing popularity of URIs, especially with their increased
importance in RDF, it becomes more important than ever to have URIs for all
sorts of items. Already, protocols like isbn: allow the use of some types of
physical items, but this still leaves quite a lot left."
http://lists.w3.org/Archives/Public/uri/2000Oct/0006.html
It would be nice to have official URIs for these things.
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
Ken MacLeod wrote:
> I don't see any reason an existing taxonomy couldn't just be
> represented by a "topic system URI" (the URI of the taxonomy) and
> "human readable text" (a topic within that taxonomy system).
Yes I agree.
Seth
Aaron Swartz <aswartz@...> writes:
> Seth Russell <seth@...> wrote:
>
> > When language works, it works because each of us uses the same
> > word for the same thing. So the semantic web is trying to make
> > its language work by using the same URI for the same thing.
> >
> > *** But if we use different URIs for the same thing, it doesn't
> > work! ***
>
> Hmm, let's try replacing URI with word, as you've implied above:
>
> *** But if we use different words for the same thing, it doesn't
> work! ***
>
> Have you looked at a thesaurus recently? ;-)
>
> Anyway, the point is, that it's perfectly OK to have multiple words
> (or URIs, as the case may be) that represent a subject. They all
> have slightly different meanings, but one can say (or make an RDF
> assertion) that they're all similar, or represent the same thing.
Clarify please: we *want* multiple URIs for the same thing? (or "want
to allow ...")
As I understand it, processing systems pretty much have to take a URI
at face value, different URIs mean different things, always. The
difference may be ever so subtly small, but you know that if you've
got a different URI you've got the potentential of some difference
between the resources referenced.
So, if two parties arbitrarily come up with two different URIs for the
same exact thing, they're hosing the processors, who can't ever know
that the two URIs refer to the same thing.
-- Ken
P.S. I can understand two widely seperate parties coming up with
different URIs in a fit of convergent evolution, and there might be a
way (RDF Schemas?) of indicating true equivalence for the duration
until one can be phased out, but that's not what we mean here: what is
meant here is arbitrarily picked URIs that actually refer to the same
thing, as if just anybody is allowed to create an algorithm for
assigning URIs to other people's stuff.
Ken MacLeod <ken@...> wrote:
> Clarify please: we *want* multiple URIs for the same thing? (or "want
> to allow ...")
Glad to. The issue we're dealing with is describing items which the Web
isn't traditionally designed to handle (abstract concepts, products, etc.)
and thus don't have a typical URI. It is unlikely that these concepts will
ever have a URI, since it is very difficult to define exactly what we are.
To quote Wittgenstein, Philosophical Investigations (3rd Edition, p. 32e):
<q>we see a complicated network of similarities overlapping and
cris-crossing: sometimes overall similarities; sometimes similarities of
detail.
67. I can think of no better expression to characterize these resemblances
than "family resemblances"; for the various resemblances between members of
a family: build, features, colour of eyes, gait, temperament, etc. etc.
overlap and cris-cross in the same way.</q>
In the same way, we have many URIs, each of which describes a particular
person or organization's view of a concept. All these URLs are different,
and refer to slightly different items, but have a relationship -- a family
resemblance -- as Wittgenstein says.
Without a GOD.org, I doubt it can be any other way. We (and RDF processors)
have to learn to deal with this. Headline Viewer has already run into this
problem with its aliases file -- it lists items (RSS files, in particular)
which each have the same goal (trying to describe a certain site) but can
each do it in a slightly different way, or a slightly different URL. These
are different things, but they share a family resemblance: they attempt to
do the same thing.
I assure you more of these such files will spring up. (Disclosure: I hope to
make get.theinfo.org a source for such things.) They will provide valuable
links between similar items, or items that attempt the same thing. They will
help, but are not a perfect solution.
I believe, this is just something we'll need to learn to live with.
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
At the request of a few people who are members of both the RSS-dev and
syndication list, I'm forwarding this message to the list.
TNL
Date: Fri, 13 Oct 2000 15:19:24
-0400
To: syndication@egroups.com
From: Tristan Louis <tristan@...>
Subject: Some suggestions for RSS .92
I'd like to suggest a few optional additions to the specification. Here
are some ideas I'd like to throw around for discussion:
At the item level:
<date></date>: This would allow us to specify a particular
date for an item. I think it would be nice for those of us who have
several days' worth of content in their RDF channel.
At the channel level:
These could be encapsulated in to an <external></external>
section that would include all links to outside of the channel.
<about></about> : Much like <link></link> points
to the page the channel is for <about></about> could point to
a page of information about this channel. this could link to a FAQ or
more information about the channel.
<wireless></wireless>: Points to a page where wireless
devices can go.
<broadband></broadband>: Points to a page where broadband
devices can go.
<narrowband></narrowband>: Points to a page where narrowband
devices (browsers for blind people, text-only browsers, etc..) can
go
<p3></p3>: Points to a P3P page to check the privacy
rules
<sound></sound>: Points to either a VXML source file (which
can be read by a VXML browser) or a sound file. For example, it could
serve up a radio feed related to this story.
<video></video>: Same as above with video or SMIL file.
That said, here's what a source could look like (changes are bolded and
URLs are fictional (but I cut and pasted my .91 channel content for speed
reasons)):
-------------- Suggested RSS .92 code starts here
--------------------
<item> <title>Story
1</title> <link>http://www.tnl.net/newsletter/anewstory.html</link>
<description>Can
you believe this. We're actually describing the content of the link
here</description> <date>10/13/2000</date> </item>
<item> <title>Some
older story</title> <link>http://www.tnl.net/newsletter/olderstory.html</link>
<description>Can
you believe this. We're actually describing the content of the link
here</description> <date>01/01/2000</date> </item>
</channel>
</rss>
-------------- Suggested RSS .92 code ends here
--------------------
As part of the deal, I'd also move the original channel link and image
link into the external field under a single link header (unless some
people can tell me where they have a different link for the image and the
channel.
Your thoughts on this?
TNL
PS: Full disclosure time - My interest in syndication is related to both
past and present. For starters, I have my own personal web site that I
use to publish a newsletter (and offer a channel). Providing an easy to
use format for summary distribution is a great way to increase traffic to
it and expose people to my ideas.
Second, I'm starting a company called Moveable Media
(http://www.moveablemedia.com),
which is trying to bridge the gap between online and offline media. While
online syndication is WAY in the future for us (we're first focusing on
providing tools that will allow people to deal with freelancers), it is
something that we are seeing as a potential future arena for us.
| Tristan
Louis
| Home: tristan@... | 140 e. 28th
st. |
| Chairman and CEO |
http://www.tnl.net
| Suite
8C
|
| Moveable Media, Inc. | Boot up, Log In,Geek out | New York, NY 10016
|
To subscribe to the TNL.net newsletter, just send email to
TNLnet-subscribe@...
While much of the taxonomic discussion on this list has been about fitting
taxonomies into current systems (such as dmoz or Yahoo), little has been
discussed about a different way of looking at it. I believe Seth suggested
this, but what about taxonomic anarchy.
This has come up in RSS before, as suggested by Jon Udell:
http://discuss.userland.com/msgReader$10830
The basic idea is that instead of pointing at something in a designated
hierarchy, you use items (Seth suggested URIs, Jon plain text) that begin to
describe your item. Your item would at the intersection (AND operator) of
all these categories.
Jon suggests a system of natural selection that had a strong appeal to me
when I first read about it. Subjects that become popular are used more,
those that aren't die out.
I'd just like to throw it out there,
--
Aaron Swartz <aswartz@...>| advertising advertises advertising
<http://www.swartzfam.com/aaron/> | - Marshall McLuhan
AIM: Jedi of Pi | ICQ: 33158237 | we don't - <http://theinfo.org/>
Aaron Swartz <aswartz@...> wrote:
> This has come up in RSS before, as suggested by Jon Udell:
Dave Winer kindly corrected me that it was he who suggested the idea, not
Jon. While Jon posted the article to the forum, he states:
"Today Dave Winer and I were kicking around some ideas for merging the flow
of RSS channel items into some kind of directory scheme. [...] So here's
what we came up with."
My sincere apologies to everyone for the mistake,
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
How should the taxonomy module identify a topic ?
Without using the taxonomy module, DC identifies subjects through
natural language words.
During the discussions about taxonomy, 2 different systems have been
proposed to identify a topic:
P1: Scheme URI + plain text
---------------------------
In this case, a topic is identified through an URI defining the taxonomy
system used and a plain text value (keyword or path) which is an
identifier within the system.
Examples (taken from posts on this list):
("URI", "value")
("http://www.oasis-open.org/cover/country3166.html", "AL")
("http://dmoz.org/", "Shopping:Retailers")
("http://www.oreillynet.com/", "python")
("http://www.dictionary.com/", "python")
P2: Topic URI
-------------
The topic is directly identifies through a URI.
Examples:
http://www.oasis-open.org/cover/country3166.html#ALhttp://dmoz.org/Shopping/Retailers/http://www.oreillynet.com/pythonhttp://www.dictionary.com/cgi-bin/dict.pl?term=python
Pros and cons (short version):
-----------------------------
P1 seems simpler since the system is defined and the text can be used
both for display and to construct a link on the URI.
P1 supposes though that the application knows which algorithm should be
used to calculate the link from the scheme URI and the text value.
The URIs defined in P2 can be directly used as RDF identifiers.
P2 is in line with the semantic web where URIs are considered as names.
P2 is more general than P1 since it allows to use taxonomy schemes where
the topic URIs cannot easily be built from the scheme URI and the text
value.
Thoughts ?
Eric
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Eric van der Vlist <vdv@...> writes:
> How should the taxonomy module identify a topic ?
>
> Without using the taxonomy module, DC identifies subjects through
> natural language words.
>
> During the discussions about taxonomy, 2 different systems have been
> proposed to identify a topic:
>
> P1: Scheme URI + plain text
> ---------------------------
>
> In this case, a topic is identified through an URI defining the taxonomy
> system used and a plain text value (keyword or path) which is an
> identifier within the system.
>
> Examples (taken from posts on this list):
>
> ("URI", "value")
> ("http://www.oasis-open.org/cover/country3166.html", "AL")
> ("http://dmoz.org/", "Shopping:Retailers")
> ("http://www.oreillynet.com/", "python")
> ("http://www.dictionary.com/", "python")
>
> P2: Topic URI
> -------------
>
> The topic is directly identifies through a URI.
>
> Examples:
>
> http://www.oasis-open.org/cover/country3166.html#AL
> http://dmoz.org/Shopping/Retailers/
> http://www.oreillynet.com/python
> http://www.dictionary.com/cgi-bin/dict.pl?term=python
>
> Pros and cons (short version):
> -----------------------------
>
> P1 seems simpler since the system is defined and the text can be used
> both for display and to construct a link on the URI.
>
> P1 supposes though that the application knows which algorithm should be
> used to calculate the link from the scheme URI and the text value.
>
> The URIs defined in P2 can be directly used as RDF identifiers.
>
> P2 is in line with the semantic web where URIs are considered as names.
>
> P2 is more general than P1 since it allows to use taxonomy schemes where
> the topic URIs cannot easily be built from the scheme URI and the text
> value.
Hmm, I think these pros and cons miss the point slightly.
The suggestion for P1 is a practical admission that there are no URIs
or conceivable algorithms for linking the topic within the topic
system, it's a simple human dart-shoot. All that is being stated with
P1 is that, "from topic system 'dmoz.org', I found topic
'Shopping:Retailers' that I think might categorize my item/channel".
One cannot derive any more information out of that. The best an RSS
processor can do with this is render the topic and provide a link to
a URL where that topic was picked from.
Our current proposal for P2 has us creating URIs out of thin air
against somebody else's topic systems. Merely having a name (URI) is
not a useful thing unless the context of that name can be reused
elsewhere. Having an arbitrary name is arguably no better than not
having a name at all!
I believe it is not practical for RSS-DEV alone to come up with URI
generation schemes for other projects' URI spaces. While we're doing
that, it's likely that the DC, RDF, and the Podunk Homebrew Club
mailing lists are also off creating URI generation schemes for the
same systems, all incompatible and, therefore, equally arbitrary.
On the other hand, if someone wants to form a new mailing list or WG
*expressly* for the purpose of creating URI schemes against existing
systems, that would be incredibly useful and beneficial to all RDF and
KR users. (I think I may have seen one at one point, but I don't
recall where.)
In the meantime, though, P1 is for topic systems that do not yet have
credible URI names, and P2 is for when they do become available, but
there aren't any yet and RSS-DEV should not take on the role of
creating them.
-- Ken
Ken MacLeod wrote:
>
> Hmm, I think these pros and cons miss the point slightly.
I am afraid I am still missing it, then :(
> The suggestion for P1 is a practical admission that there are no URIs
> or conceivable algorithms for linking the topic within the topic
> system, it's a simple human dart-shoot. All that is being stated with
> P1 is that, "from topic system 'dmoz.org', I found topic
> 'Shopping:Retailers' that I think might categorize my item/channel".
> One cannot derive any more information out of that. The best an RSS
> processor can do with this is render the topic and provide a link to
> a URL where that topic was picked from.
>
> Our current proposal for P2 has us creating URIs out of thin air
> against somebody else's topic systems. Merely having a name (URI) is
> not a useful thing unless the context of that name can be reused
> elsewhere. Having an arbitrary name is arguably no better than not
> having a name at all!
>
> I believe it is not practical for RSS-DEV alone to come up with URI
> generation schemes for other projects' URI spaces. While we're doing
> that, it's likely that the DC, RDF, and the Podunk Homebrew Club
> mailing lists are also off creating URI generation schemes for the
> same systems, all incompatible and, therefore, equally arbitrary.
>
> On the other hand, if someone wants to form a new mailing list or WG
> *expressly* for the purpose of creating URI schemes against existing
> systems, that would be incredibly useful and beneficial to all RDF and
> KR users. (I think I may have seen one at one point, but I don't
> recall where.)
>
> In the meantime, though, P1 is for topic systems that do not yet have
> credible URI names, and P2 is for when they do become available, but
> there aren't any yet and RSS-DEV should not take on the role of
> creating them.
Of course not.
Taxonomy is a module and, as any module it's optional.
If you have a topic which is a good fit for your channel and/or item,
you can use it, otherwise you can still use plain text dc:subject to
categorize it or not categorize it at all.
If you don't have the information, you should surely not invent it and,
like you, I am convinced that it's out of the scope of RSS to invent or
even advise one.
On the contrary, it's because I have no idea of how these URIs are build
that I think the URI designating the topic should be used.
Eric
> -- Ken
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Eric van der Vlist <vdv@...> writes:
> Ken MacLeod wrote:
> >
> > Hmm, I think these pros and cons miss the point slightly.
>
> I am afraid I am still missing it, then :(
It's entirely possible I'm misreading your (and Aaron's similar)
posts.
When you say:
> P2: Topic URI
> -------------
>
> The topic is directly identifies through a URI.
>
> Examples:
>
> http://www.oasis-open.org/cover/country3166.html#AL
> http://dmoz.org/Shopping/Retailers/
> http://www.oreillynet.com/python
> http://www.dictionary.com/cgi-bin/dict.pl?term=python
I can't tell if you're using them simply as examples of what could or
should be (since there's no normative source for these URIs), and then
basing the development of P2 on them being developed; or if you're
suggesting that these URI schemes "effectively exist" now and as soon
as P2 is finalized, we'll start using these types of URLs right away.
(I'm cool with the former, but not the latter.)
You might have answered this in a response to a message from Seth, but
I can't tell for sure there either,
<http://www.egroups.com/message/rss-dev/813>.
-- Ken
I wrote:
> Eric van der Vlist <vdv@...> writes:
>
> > P2: Topic URI
> > -------------
> >
> > The topic is directly identifies through a URI.
> >
> > Examples:
> >
> > http://www.oasis-open.org/cover/country3166.html#AL
> > http://dmoz.org/Shopping/Retailers/
> > http://www.oreillynet.com/python
> > http://www.dictionary.com/cgi-bin/dict.pl?term=python
>
> I can't tell if you're using them simply as examples of what could
> or should be (since there's no normative source for these URIs), and
> then basing the development of P2 on them being developed; or if
> you're suggesting that these URI schemes "effectively exist" now and
> as soon as P2 is finalized, we'll start using these types of URLs
> right away.
I had a chance to chat with Eric on IRC and we cleared up my
confusion: yes, these are only example URI schemes, to effectively use
this model we will need to have normative sources for taxonomy URI
schemes.
Thanks Eric, and sorry for the confusion!
-- Ken
Ken MacLeod wrote:
>
> I had a chance to chat with Eric on IRC and we cleared up my
> confusion: yes, these are only example URI schemes, to effectively use
> this model we will need to have normative sources for taxonomy URI
> schemes.
>
> Thanks Eric, and sorry for the confusion!
My fault I was the one who was writing :) ...
I'd like to state or confirm that I think the biggest work and challenge
will be to define (or find) the right taxonomy schemes and that I
consider it as out of the scope of RSS itself.
We need to make sure our model for the taxonomy module will allow us to
use these systems, though.
To make things more concrete, the only operational example I can give is
the very simple taxonomy scheme I have defined on XMLfr which could be
extended to exchange info between sites using a XMLNews-Story DTD.
(Again, it's an example and the definition of such scheme is out of the
scope of our group.)
The idea is to take a base URI, to add the XMLNews-Story element name
and its value.
For instance, to express the fact that a document is containing an
"object.title" element whose value is "Apache" (i.e. the web server),
you would use the URI:
http://xmlfr.org/index/object.title/Apache/
while to say that it contains an "org" element whose value is "Apache"
(i.e. the Apache organization), you'd use:
http://xmlfr.org/index/org/Apache/
This example is real simple, the harvesting of the metadata using this
taxonomy can be done through a single XSLT transformation, but it's
already giving you more info than the keyword "Apache" alone.
IMHO such simple taxonomy schemes are likely to coexist with more
general or normative ones and conversion systems will eventually be
developed between them.
A RSS 1.0 using the current syntax for the taxonomy module is available
at http://xmlfr.org/actualites/general.rss10 .
(please note that the syntax of this example is NOT what I'd like to
propose for the taxonomy but the current one and that the example
doesn't show mixed taxonomy and single text keywords).
Eric
> -- Ken
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Eric van der Vlist <vdv@...> wrote:
> How should the taxonomy module identify a topic ?
>
> During the discussions about taxonomy, 2 different systems have been
> proposed to identify a topic:
I was thinking of a combination of the two:
P3: Scheme URI + Topic URI + Plain Text
---------------------------------------
In this case a topic is directly identified through a URI. However, a plain
text description is provided to help out a user and a Scheme URI is provided
to assist processing by automated systems.
Examples:
("scheme URI","topic URI","plain text")
("http://dmoz.org","http://dmoz.org/Shopping/Retailers/","Shopping:
Retailers")
would be displayed in HTML as:
Category: <a href="http://dmoz.org/Shopping/Retailers/">Shopping:
Retailers</a> (<a href="http://dmoz.org/">dmoz.org</a>)
Thoughts?
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
Aaron Swartz wrote:
>
> Eric van der Vlist <vdv@...> wrote:
>
> > How should the taxonomy module identify a topic ?
> >
> > During the discussions about taxonomy, 2 different systems have been
> > proposed to identify a topic:
>
> I was thinking of a combination of the two:
>
> P3: Scheme URI + Topic URI + Plain Text
> ---------------------------------------
>
> In this case a topic is directly identified through a URI. However, a plain
> text description is provided to help out a user and a Scheme URI is provided
> to assist processing by automated systems.
>
> Examples:
>
> ("scheme URI","topic URI","plain text")
> ("http://dmoz.org","http://dmoz.org/Shopping/Retailers/","Shopping:
> Retailers")
>
> would be displayed in HTML as:
>
> Category: <a href="http://dmoz.org/Shopping/Retailers/">Shopping:
> Retailers</a> (<a href="http://dmoz.org/">dmoz.org</a>)
>
> Thoughts?
I wanted to bring this into the discussion later on.
I think that before defining which information we want to provide, we
need to agree on how we can identify a topic...
My proposal for a taxonomy syntax without "beginning by the beginning"
has proved to be difficult to discuss because we seemed to lack a common
ground !
Eric
> --
> Aaron Swartz |"This information is top security.
> <http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
> <http://www.theinfo.org/> | - Marshall McLuhan
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
I think, at minimum, we should distinguish between a set of keywords which we
"and" together
to form the actual classification, as opposed to a set of alternative
classifications. How
are we to know which logical operator to apply (and / or) in the current plans?
Seth
Seth Russell <seth@...> wrote:
> I think, at minimum, we should distinguish between a set of keywords which we
> "and" together to form the actual classification, as opposed to a set of
> alternative classifications. How are we to know which logical operator to
> apply (and / or) in the current plans?
I would think it would always be AND. Can you think of an example where a
keyword would be ORed together? Or are you imply a usage like this:
((http://dmoz.org/Art/
OR
http://yahoo.com/Art/)
AND
http://example.com/DeadSquirrels/)
implying that dmoz.org and yahoo are interchangeable? How would this be used
in a real life application?
A tad confused,
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
Aaron Swartz wrote:
> Seth Russell <seth@...> wrote:
>
> > I think, at minimum, we should distinguish between a set of keywords which
we
> > "and" together to form the actual classification, as opposed to a set of
> > alternative classifications. How are we to know which logical operator to
> > apply (and / or) in the current plans?
>
> I would think it would always be AND. Can you think of an example where a
> keyword would be ORed together? Or are you imply a usage like this:
I think Rael gave some good examples of alternative classifications in [1]:
http://www.oreillynet.com/python/http://dmoz.org/Computers/Programming/Languages/Python/
"Anding" those two is incoherant. Another real world example might be
alternative
languages. I dont think we would ever need to make a complicate and/or
expression,
but where there are multiple topics we need to know if they are alternative or
conjunctive.
[1] http://www.egroups.com/message/rss-dev/819
Seth
Seth Russell <seth@...> wrote:
> I think Rael gave some good examples of alternative classifications in [1]:
>
> http://www.oreillynet.com/python/
> http://dmoz.org/Computers/Programming/Languages/Python/
>
> "Anding" those two is incoherant.
Why? It would say that the item was about what O'Reillynet calls Python, AND
what dmoz calls Python.
Again, perhaps an example of an actual use-case would be helpful here.
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
Howdy,
On Sun, 15 Oct 2000, Aaron Swartz wrote:
> Seth Russell <seth@...> wrote:
>
> > I think Rael gave some good examples of alternative classifications in [1]:
> >
> > http://www.oreillynet.com/python/
> > http://dmoz.org/Computers/Programming/Languages/Python/
> >
> > "Anding" those two is incoherant.
>
> Why? It would say that the item was about what O'Reillynet calls Python, AND
> what dmoz calls Python.
"You say tomato, I say tomato,
You say potato, I say potato..."
Ok, so it doesn't work as a textual representation, but you get the drift.
It's perfectly reasonable to classify things across various different
dimensions -- and even more than once in the same dimension. The more
"as in"s one provides, the closer we come to clarifying meaning.
Explanation by example is a powerful method of communication, especially
when semantics are scant. "Free as in America" by itself is nowhere near
as clear as "Free as in America, a bird, liberty, ..."
Rael
Ps. By the way, nobody says "potAHto" :-)
------------------------------------------------------------------
Rael Dornfest rael@...
Maven, http://www.oreillynet.com/~rael
The O'Reilly Network http://meerkat.oreillynet.com
------------------------------------------------------------------
Aaron Swartz wrote:
> Seth Russell <seth@...> wrote:
>
> > I think Rael gave some good examples of alternative classifications in [1]:
> >
> > http://www.oreillynet.com/python/
> > http://dmoz.org/Computers/Programming/Languages/Python/
> >
> > "Anding" those two is incoherant.
>
> Why? It would say that the item was about what O'Reillynet calls Python, AND
> what dmoz calls Python.
Wiggy, the natural language usage of 'and' is notoriously pecular in this usage;
but computers only know 'and' in the mathematical sense as the join of two sets.
One is not talking here *only* about those things that *both* O'Reilly and Dmoz
considers to be "Python": for then you would exclude from each those listings
that were not common to both. Rather one is taking about both classifications
in
parallel and saying that you can use either equally as well.
.... or were you pulling my leg :)
Seth
Seth Russell <seth@...> wrote:
>>> I think Rael gave some good examples of alternative classifications in [1]:
>>>
>>> http://www.oreillynet.com/python/
>>> http://dmoz.org/Computers/Programming/Languages/Python/
>>>
>>> "Anding" those two is incoherant.
>>
>> Why? It would say that the item was about what O'Reillynet calls Python, AND
>> what dmoz calls Python.
>
> Wiggy,
Wiggy?
> the natural language usage of 'and' is notoriously pecular in this usage;
> [...] One is not talking here *only* about those things that *both* O'Reilly
> and Dmoz considers to be "Python": [...] Rather one is taking about both
> classifications in parallel and saying that you can use either equally as
> well.
Again this would be made clearer by an actual use case. I understand about
the mathematical usage, but I have trouble seeing its application in this
situation. So, would we be saying that this article was only about the
intersection of what O'Reilly considers Python and say, what dmoz considers
WAP (for an article about Python outputting WML files). What would this even
mean real life? The only thing I can see a real use for is a sort of logical
OR -- that is, on my site, I categorize the news item in the Python section,
and in the WAP section. How would a logical AND be used?
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
Howdy,
On Sun, 15 Oct 2000, Aaron Swartz wrote:
> Seth Russell <seth@...> wrote:
>
> >>> I think Rael gave some good examples of alternative classifications in
[1]:
> >>>
> >>> http://www.oreillynet.com/python/
> >>> http://dmoz.org/Computers/Programming/Languages/Python/
> >>>
> >>> "Anding" those two is incoherant.
> >>
> >> Why? It would say that the item was about what O'Reillynet calls Python,
AND
> >> what dmoz calls Python.
Again, if you drop the need for a conjunction choice and see these as
"as in"s, even "see also"s, it might make more sense to you. It's less
about placing items in little boxes and more about providing some context
for the human/computer consumer.
Rael
------------------------------------------------------------------
Rael Dornfest rael@...
Maven, http://www.oreillynet.com/~rael
The O'Reilly Network http://meerkat.oreillynet.com
------------------------------------------------------------------
Rael Dornfest <rael@...> wrote:
> Again, if you drop the need for a conjunction choice and see these as
> "as in"s, even "see also"s, it might make more sense to you. It's less
> about placing items in little boxes and more about providing some context
> for the human/computer consumer.
Ahh, now that makes sense.
--
Aaron Swartz |"This information is top security.
<http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
<http://www.theinfo.org/> | - Marshall McLuhan
I must admit I don't get the point either and just don't see how you can
have a "or" combination of keywords at a statement level at least.
You should be able to differentiate between "and" and "or" in a query
(saying that you want to retrive objects with either ("art" and "dead
squirrels") or ("art" or "dead squirrels")), but does it make sense to
say that the keywords "art" or "dead squirrels" are relevant ?
If we admit that taxonomy topics are keywords from controlled
vocabulary, we don't have to allow or combination either, or have I
missed something ?
Eric
Aaron Swartz wrote:
>
> Seth Russell <seth@...> wrote:
>
> > I think, at minimum, we should distinguish between a set of keywords which
we
> > "and" together to form the actual classification, as opposed to a set of
> > alternative classifications. How are we to know which logical operator to
> > apply (and / or) in the current plans?
>
> I would think it would always be AND. Can you think of an example where a
> keyword would be ORed together? Or are you imply a usage like this:
>
> ((http://dmoz.org/Art/
> OR
> http://yahoo.com/Art/)
> AND
> http://example.com/DeadSquirrels/)
>
> implying that dmoz.org and yahoo are interchangeable? How would this be used
> in a real life application?
>
> A tad confused,
>
> --
> Aaron Swartz |"This information is top security.
> <http://swartzfam.com/aaron/>| When you have read it, destroy yourself."
> <http://www.theinfo.org/> | - Marshall McLuhan
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
--
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
There still is some confusion about what exactly the rdf:about attribute of the
channel element should contain.
Is it
a) the UR{I|L} of the channel itself (as the example in the current spec as well
as the Meerkat feed at [1] suggest)
b) the UR{I|L} of the resorce described by the channel as suggested in the
thread starting at [2]
From my current understanding of RDF a) would be correct usage, because the
resource described is the RSS file itself.
This way, the link element cannot be identical to the rdf:about attribute of the
channel element, as the link is defined to be: "The
URL to which an HTML rendering of the channel title will link".
Using option a) means that we have no way to state what a channel describes
(i.e. a website, or part of that or whatever).
-markus
[1] http://www.oreillynet.com/meerkat/?_fl=rss10
[2] http://www.egroups.com/message/rss-dev/551
Rael Dornfest <rael@...> writes:
> On 15 Oct 2000, Ken MacLeod wrote:
>
> > 2) Because of [including DC in RSS 1.0], at some point in time,
> > likely by by 1.1 (three months?) we are going to face the
> > design issue of rich-content vs. simple-content (as with DC
> > and Taxonomy) and I don't want to see two modules for both
> > sides every time. I especially don't want a DC-PlainText
> > module and a DC-Rich module. Let's fix this in 1.0 and not
> > have to try to be backwards compatible with 1.1. I think I
> > have a proposal for this.
>
> Adoption of the DC module does not in any way impact the ability (or lack
> thereof) to extend semantics. I don't believe adopting a simple module
> precludes augmentation when/where necessary. Dublin Core is a perfect
> case in point as they work on introducing just such semantics to an
> otherwise historically flat system[d]. In situations such as dc:subject
> where DC does provide a base on which to build, this will only require one
> module providing extensions to the semantics.
> [d] http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/
This misses the issue I see. I think this issue would be clearer with
an infoset (a prose description of RSS's data model), here's a stab at
it using one concrete element.
When we roll out RSS 1.0 with DC, the information in dc:creator will
be:
dc:creator
A string naming the entity primarily responsible for making the
content of the resource. Examples of a Creator include a
person, an organisation, or a service. Typically, the name of a
Creator should be used to indicate the entity.
Later on, when DC semantics are extended, that information now becomes:
dc:creator
A string naming or rich-RDF describing the entity primarily
responsible for making the content of the resource. Examples of
a Creator include a person, an organisation, or a service.
Typically, the name of a Creator should be used to indicate the
entity.
The second model is just fine as a model, I rather like it ;-).
The issue is migrating tools from supporting the first model (just a
string) to the second model (a string or RDF statements). That's not
a minor thing, we can't just start using the new, second model and
expect today's tools to produce anything but unexpected results.
The gist of my proposal for supporting this is simply to document that
we expect the model to look like the second one eventually, so all
tools and applications written today must expect this. To support
this proposal, we need to at least provide example RSS files using
both richer content (even if we haven't nailed down it's full RDF
schema) and plain content, and make it clear how the plain content is
pulled from the richer content, since that's what the tools will be
written to understand now.
The difficulty in my proposal, as applied generally, is deciding which
elements this covers: all of them, or just identified, module-specific
ones. Somewhat related is marked-up text in things like <title> and
<description>, which, iirc, current RSS practice indicates is already
being done.
-- Ken
Howdy,
On 16 Oct 2000, Ken MacLeod wrote:
> Rael Dornfest <rael@...> writes:
>
> > On 15 Oct 2000, Ken MacLeod wrote:
> >
> > > 2) Because of [including DC in RSS 1.0], at some point in time,
> > > likely by by 1.1 (three months?) we are going to face the
> > > design issue of rich-content vs. simple-content (as with DC
> > > and Taxonomy) and I don't want to see two modules for both
> > > sides every time. I especially don't want a DC-PlainText
> > > module and a DC-Rich module. Let's fix this in 1.0 and not
> > > have to try to be backwards compatible with 1.1. I think I
> > > have a proposal for this.
> >
> > Adoption of the DC module does not in any way impact the ability (or lack
> > thereof) to extend semantics. I don't believe adopting a simple module
> > precludes augmentation when/where necessary. Dublin Core is a perfect
> > case in point as they work on introducing just such semantics to an
> > otherwise historically flat system[d]. In situations such as dc:subject
> > where DC does provide a base on which to build, this will only require one
> > module providing extensions to the semantics.
>
> > [d] http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/
>
> This misses the issue I see. I think this issue would be clearer with
> an infoset (a prose description of RSS's data model), here's a stab at
> it using one concrete element.
>
> When we roll out RSS 1.0 with DC, the information in dc:creator will
> be:
>
> dc:creator
> A string naming the entity primarily responsible for making the
> content of the resource. Examples of a Creator include a
> person, an organisation, or a service. Typically, the name of a
> Creator should be used to indicate the entity.
>
> Later on, when DC semantics are extended, that information now becomes:
>
> dc:creator
> A string naming or rich-RDF describing the entity primarily
> responsible for making the content of the resource. Examples of
> a Creator include a person, an organisation, or a service.
> Typically, the name of a Creator should be used to indicate the
> entity.
>
> The second model is just fine as a model, I rather like it ;-).
Good on you, Ken. Nicely put.
> The issue is migrating tools from supporting the first model (just a
> string) to the second model (a string or RDF statements). That's not
> a minor thing, we can't just start using the new, second model and
> expect today's tools to produce anything but unexpected results.
>
> The gist of my proposal for supporting this is simply to document that
> we expect the model to look like the second one eventually, so all
> tools and applications written today must expect this. To support
> this proposal, we need to at least provide example RSS files using
> both richer content (even if we haven't nailed down it's full RDF
> schema) and plain content, and make it clear how the plain content is
> pulled from the richer content, since that's what the tools will be
> written to understand now.
Agreed.
> The difficulty in my proposal, as applied generally, is deciding which
> elements this covers: all of them, or just identified, module-specific
> ones. Somewhat related is marked-up text in things like <title> and
> <description>, which, iirc, current RSS practice indicates is already
> being done.
I believe this can be done on a module by module basis. As for DC, I
believe we could put a general caveat in the intro since DC is advocating
this for pretty much every element; pointing to the "Guidance"[1] document
would go a long way too.
Rael
[1] http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/
------------------------------------------------------------------
Rael Dornfest rael@...
Maven, http://www.oreillynet.com/~rael
The O'Reilly Network http://meerkat.oreillynet.com
------------------------------------------------------------------
Send Email
