Concepts as URIs - Are tag clouds good enough for user-modeling?
Francois Dongier
represented in the APML.": does APML need a richer representation of
concepts than the one we have now?
In the current APML spec, concepts are just names, with entries such
as:
IMPLICIT
[concept key="soccer" value=0.9 source=Particls] ; according to
Particls, I like "soccer" a lot
[concept key="Harry Potter" value=0.7 source=Amazon] ; Amazon
believes I like Harry Potter somewhat
[concept key="George Harrison" value=0.8 source=last.fm] ; Last.Fm
knows I like George Harrison
[concept key="Céline Dion" value=-0.6 source=last.fm] ; and Céline
Dion not so much
[source key="www.lemonde.fr" value = 0.7 source=FeedDemon] ; FeedDemon
observed that I spend a lot of time reading articles from "lemonde.fr"
[author key="Scoble" value=0.6 source=Particls]
[...]
EXPLICIT
[concept key="collective intelligence" value=1.0 source=Particls] ;
I told Particls this is one of my favorite topics
[...]
So, there is a little more info in the APML file than in a tag-cloud:
it stores the origin of the information (in the "source=" field), and
it also makes an interesting distinction between implicit (deduced)
and explicit (user-provided) data.
Anyway, there is an obvious 1-1 correspondence between the core of our
current APML files (made of concept-value pairs) and tag-clouds: they
are equivalent representations. In other words, there is an obvious
translation that can convert the core of an APML file to the
corresponding tag-cloud and conversely.
Now a tag cloud is great to give *you*, a human reader, an overall
idea about what's popular in a community, or about what a user
generally likes. It can also be a pretty fair representation of what
an article talks about. But if you were a computer, it wouldn't mean
much to you: it's just a list of terms. And if you (just think you're
a computer for a minute) were trying to use a tag cloud to target
interesting content to a particular user, while filtering out the
irrelevant stuff, you would feel a bit uneasy...
I believe that tag-clouds and the current AMPL spec (concepts as
names) may be good enough for some real improvement in targeted
advertising, but will be insufficient for good news filtering. The
life of a news filtering engine would be made simpler if the APML file
contained entries such as
[concept key="http://dbpedia.org/resource/George_Harrison" value=0.8
source=last.fm]
rather than
[concept key="George Harrison" value=0.8 source=last.fm]
Some advantages of using URIs instead of names are:
1. to eliminate the ambiguity of reference (it can make clear that the
interest is about George Harrison the singer and not about George
Harrison the senator)
2. to connect the identified resources to other objects (also part of
the same "web of data"). When a resource is identified (not just
named), you can instantly get a lot of info about it, some of which
may be useful to help you solve your problem.
"Concepts as URI" still makes the APML file similar to a tag-cloud,
but now each tag in the cloud is connected to lots of other things.
In the wiki, Paul says : "Personally, I believe that if URIs are
introduced, we will need to continue to keep simple entries available
in the APML, lest introducing additional complexity in actual
interpreting the document."
I don't think the complexity will be in interpreting APML files
containing URI's: if an APML-importing service is happy to work with
just the name, it is trivial to get it from the URI (to go from
http://dbpedia.org/resource/George_W._Bush to the name "George W.
Bush", just look at the HTML Title tag).
In other words, the fact that URI's gives your APML-importing program
access to a very complex world of connected sentences doesn't imply
that your software has to be very complex. Navigating in the world of
data (and using the info in it) is likely to be somewhat complex. But
no program will be forced to do this. If you like to keep it simple,
no problem: just ignore this data, and don't attempt to make sense of
it.
I agree however that finding the right URI to put in the APML file
instead of just a keyword will sometimes be non-trivial.
Chris Saad
Again, while allowing for hard liking to URIs, in the end enforcing such a link will make things very difficult for a lot of non-specialized developers to understand and implement and will break the 'really simple attention' philosophy.
So in summary, my feeling is that URIs for concepts should be supported, but not required.
Chris
Paul Jones in the wiki asked "how to best semantically enable entities
represented in the APML.": does APML need a richer representation of
concepts than the one we have now?
In the current APML spec, concepts are just names, with entries such
as:
IMPLICIT
[concept key="soccer" value= 0.9 source=Particls] ; according to
Particls, I like "soccer" a lot
[concept key="Harry Potter" value=0.7 source=Amazon] ; Amazon
believes I like Harry Potter somewhat
[concept key="George Harrison" value= 0.8 source=last.fm] ; Last.Fm
[concept key="George Harrison" value= 0.8 source=last.fm]
Chris Saad
FaradayMedia.com - For Audiences of One
Particls.com - Are You Paying Attention?
Engagd.com - The Open Attention Platform
Media2.0Workgroup.org - Social, Democratic, Distributed
APML.org - The OPML of Attention
Francois Dongier
"really simple attention" approach...
It's just that the semweb community is getting very active these days
(did you see the nice "semantic web pipes" annnounced today
http://pipes.deri.org/ )? My concern is just that we don't miss the
opportunity to use a resource (the "world wide database") that is now
becoming available. This resource should, in many ways, simplify the
life of developers. And it would be too bad if a company (say, Radar
Networks) came up with an alternative format recommendation for user-
profiles, that would make the web of data easier to access than with
APML.
But after all you're probably right, simple is beautiful. And I
suppose it can in some cases be better to leave some vagueness in the
APML description of user interests, and let the APML-importing
services do the guessing. I was impressed by the Flickr tag clusters
(e.g. http://flickr.com/photos/tags/turkey/clusters ) mentioned by
Brian.
I also found interesting David's remark that "we'd like to be able to
use large APML datasets to produce statistical
trends etc much like Google does with query logs".
On the other hand, it's likely that somebody will soon come up with a
web service that guesses the URI of a particular concept in a tag-
cloud... That could be pretty nice ;-)
On 1 nov, 23:04, "Chris Saad" <ch...@faradaymedia.com> wrote:
> As someone else mentioned - I tend to think of concepts as datapoints taken
> as a whole rather than each one representing self-contained meaning. In
> other words, if the user has 'cats' and 'Siamese' then they are probably
> more interested in actual cats, specifically Siamese cats, than the musical
> cats.
>
> Again, while allowing for hard liking to URIs, in the end enforcing such a
> link will make things very difficult for a lot of non-specialized developers
> to understand and implement and will break the 'really simple attention'
> philosophy.
>
> So in summary, my feeling is that URIs for concepts should be supported, but
> not required.
>
> Chris
>
> On 11/2/07, Francois Dongier <francois.dong...@gmail.com> wrote:
>
>
>
>
>
> > Paul Jones in the wiki asked "how to best semantically enable entities
> > represented in the APML.": does APML need a richer representation of
> > concepts than the one we have now?
>
> > In the current APML spec, concepts are just names, with entries such
> > as:
>
> > IMPLICIT
> > [concept key="soccer" value=0.9 source=Particls] ; according to
> > Particls, I like "soccer" a lot
> > [concept key="Harry Potter" value=0.7 source=Amazon] ; Amazon
> > believes I like Harry Potter somewhat
> > [concept key="George Harrison" value=0.8 source=last.fm] ; Last.Fm
> > [concept key="George Harrison" value=0.8 source=last.fm]
>
> > Some advantages of using URIs instead of names are:
> > 1. to eliminate the ambiguity of reference (it can make clear that the
> > interest is about George Harrison the singer and not about George
> > Harrison the senator)
> > 2. to connect the identified resources to other objects (also part of
> > the same "web of data"). When a resource is identified (not just
> > named), you can instantly get a lot of info about it, some of which
> > may be useful to help you solve your problem.
>
> > "Concepts as URI" still makes the APML file similar to a tag-cloud,
> > but now each tag in the cloud is connected to lots of other things.
>
> > In the wiki, Paul says : "Personally, I believe that if URIs are
> > introduced, we will need to continue to keep simple entries available
> > in the APML, lest introducing additional complexity in actual
> > interpreting the document."
>
> > I don't think the complexity will be in interpreting APML files
> > containing URI's: if an APML-importing service is happy to work with
> > just the name, it is trivial to get it from the URI (to go from
> >http://dbpedia.org/resource/George_W._Bushto the name "George W.
> > Bush", just look at the HTML Title tag).
> > In other words, the fact that URI's gives your APML-importing program
> > access to a very complex world of connected sentences doesn't imply
> > that your software has to be very complex. Navigating in the world of
> > data (and using the info in it) is likely to be somewhat complex. But
> > no program will be forced to do this. If you like to keep it simple,
> > no problem: just ignore this data, and don't attempt to make sense of
> > it.
>
> > I agree however that finding the right URI to put in the APML file
> > instead of just a keyword will sometimes be non-trivial.
>
> --
gdupont
I'm not a very good participant in this group, but still have some
time to focus on interesting subject... I like the idea to introduce
semantic in APML. As I was looking into this model few months ago, I
just gave up because I thought : yet another new model but it is not
large enough to include my knowledge available in RDF... Ok, I
understand that RDF makes developer life harder (and I'm one of
them !) But I still want to keep it or at least to have a model that
could be extended to RDF.
So what about opening the door and propose an hybrid (but still
simple) solution like :
<xs:complexType name="ExplicitNodeType">
<!-- Provides the text or value of the node, such as a name or a
term -->
<xs:attribute name="label" type="xs:string" use="required"/>
<!-- Provides the uri of an identified resource (RDF style) linked
to the label -->
<xs:attribute name="uri" type="xs:string" use="optionnal"/>
<!-- Provides the rank (or score) of the node -->
<xs:attribute name="value" type="apml:NodeValueType"
use="required"/>
<!-- Allow additional attributes -->
<xs:anyAttribute/>
</xs:complexType>
Same thing for implicit concept (I should make another message on
implicit/explicit thing). The idea is to keep it simple : having a
label instead of a key (much more simple than a real unique key which
is difficult regarding the wide scope of APML...) and optionally
having the URI to point out the right resource if available. Label
could also be enlarge with language information if available and why
not providing several label for a complex interest (not sure this is
good idea).
Any comment ?
Cheers
GD
Paul Jones
I never thought I'd be the one to ask for this, since I wrote the XSD, but could we have an example in XML. And perhaps some detail on how this "RDF" style information could be used better than plain XML?
Thanks,
Paul
gdupont
As I said, that's not rdf in apml but only RDF URI to provide a
potential link between the concept provided in APML and any external
RDF resources. Thus you can keep it simple by using only label or if
you have a knowledge base, you can use URI to ensure that the concept
declared is not another label for anything else...
trying a very simple example :
<Body defaultprofile="Work">
<Profile name="Home">
<ImplicitData>
<Concepts>
<Concept label="attention" uri="http://en.wikipedia.org/wiki/
Attention" value="0.99" from="GatheringTool.com"
updated="2007-03-11T01:55:00Z" />
</Concepts>
</ImplicitData>
</Profile>
</Body>
Hope I did not forget something
Paul Jones
Is there some value in renaming the "key" field to "label"? They seem to be terms aimed toward the same goal, and if the key field were to be kept as is, then this would mean that your suggestion simply involves the addition of an optional "uri" field for items.
Perhaps I'm missing something?
Paul.
TSchultz55
Some excellent thoughts. This certainly answers the questions I
posed a few day ago.
The idea of adding an optional "uri" attribute would allow an APML
agent to delve into the semantics of a "key" (if the APML agent has
this capability).
Since APML is all about a more "intelligent" browsing experience, I
think this is a step in the right direction.
Example:
I'm currently interested in wine (the drink) and WINE (the Linux
application).
If the APML agent sees:
<Concept label="wine" value="0.87" from="GatheringTool.com"
updated="2007-07-13T09:22:00Z" />
<Concept label="WINE" value="0.27" from="GatheringTool.com"
updated="2007-02-11T04:21:00Z" />
How do we tell which is which? Are "WINE" and "wine" actually the
same thing? If they are different, which refers to the drink and
which refers to the Linux application? We can't really tell....and
this is important because in this example, their values differ
greatly.
But, as GD has proposed (and correct me if I'm wrong, but I think
we're on the same wavelength here) if the APML agent sees:
<Concept key="wine" uri="http://www.w3.org/TR/2003/PR-owl-
guide-20031215/wine#Wine" value="0.87" from="GatheringTool.com"
updated="2007-07-13T09:22:00Z" />
<Concept key="WINE" value="0.27" from="GatheringTool.com"
updated="2007-02-11T04:21:00Z" />
The agent can in fact be sure that the first concept is indeed wine,
the drink.
From here, if the APML agent is integrated with something like OpenRDF
Sesame, the agent would be able to traverse the specified semantics
document and make even more assertions for Implicit concept entries.
So overall, one small optional attribute has the ability to open a
whole new world of even "smarter" decisions based on semantics.
I think APML is a perfect vehicle for enabling semantic technologies.
Good ideas GD.
Cheers!
Tim
On Dec 4, 6:18 am, "Paul Jones" <pauljone...@gmail.com> wrote:
> Hi GD,
>
> Is there some value in renaming the "key" field to "label"? They seem to be
> terms aimed toward the same goal, and if the key field were to be kept as
> is, then this would mean that your suggestion simply involves the addition
> of an optional "uri" field for items.
>
> Perhaps I'm missing something?
>
> Paul.
>
Brian Suda
>
> GD,
>
> Some excellent thoughts. This certainly answers the questions I
> posed a few day ago.
>
> The idea of adding an optional "uri" attribute would allow an APML
> agent to delve into the semantics of a "key" (if the APML agent has
> this capability).
--- i think we keep redirecting the real issue. We don´t know how to
disambiguate, so we point at a URI, now we need to define what to
expect (or types of things to expect) at that URI. Then that is
another spec to describe concepts, which might use URIs again. See how
you end-up following your nose through several layers of formats
before potentially getting a simple answer, and even then that answer
will be in english prose because you can only describe things in
relation to each other.
> But, as GD has proposed (and correct me if I'm wrong, but I think
> we're on the same wavelength here) if the APML agent sees:
>
> <Concept key="wine" uri="http://www.w3.org/TR/2003/PR-owl-
> guide-20031215/wine#Wine" value="0.87" from="GatheringTool.com"
> updated="2007-07-13T09:22:00Z" />
> <Concept key="WINE" value="0.27" from="GatheringTool.com"
> updated="2007-02-11T04:21:00Z" />
>
> The agent can in fact be sure that the first concept is indeed wine,
> the drink.
>
> From here, if the APML agent is integrated with something like OpenRDF
> Sesame, the agent would be able to traverse the specified semantics
> document and make even more assertions for Implicit concept entries.
--- but how can it be sure? we would need another structured format
(you propose OWL) for what is at the end of the URI, then parse it,
then get some sort of machine understanding.
OR have an enumerated list of all possible keys and a predefined URI
internally for each app to dereference. Neither of which are really
desirable. The more layers of complexity the more we lose people.
> So overall, one small optional attribute has the ability to open a
> whole new world of even "smarter" decisions based on semantics.
--- the problem is that how your APML gets built could be de-void of
human intervention. If we look at the last.fm example, it is purely
pulling information from TAGS, so what URI could you use? if i am
listing to a geology podcast and tag it with "rocks" then does last.fm
output the APML with a URI to their definition of "rocks" which might
not be MY definition? you are basically asking each person to go find
a URI that actually describes their interest and then putting that in
their APML file manually - this can't really be done while compiling
keys dynamically into APML.
> I think APML is a perfect vehicle for enabling semantic technologies.
--- i would agree, but i don´t think adding a URI gives much value
because no one will do it. It is VERY hard to do dynamically because
the converting app only knows about itself, not your original
intentions.
I like the way Flickr tries to solve this disambiguation problem, by
clustering. If i have key="rock" then there is no hope for what i
mean. But is i have key="rock", key="sediment" key="geology" then you
can cluster rock with those.
A way to solve this could be a <cluster> element.
<cluster>
<Concept key="wine" value="0.87" from="GatheringTool.com"
updated="2007-07-13T09:22:00Z" />
<Concept key="vineyard" value="0.5" from="GatheringTool.com"
updated="2007-07-13T09:22:00Z" />
</cluster>
<cluster>
<Concept label="WINE" value="0.27" from="GatheringTool.com"
updated="2007-02-11T04:21:00Z" />
<Concept label="linux" value="0.1" from="GatheringTool.com"
updated="2007-02-11T04:21:00Z" />
</cluster>
This would allow the same term to appear and still be put into context
with other terms. I have no idea how this would parse or be
understood, but i think it is much easier to create clusters from
seemingly random data and data sources, without "cross polluting" all
the rock'n'roll geologists´ interests.
The alleviates the need for additional layers to dereference, and
allows for some sloppy semantics. Slang words, and even learning from
the reader's intentions... not all terms will have URIs (that is why
urbandictionary.com is so interesting), but from a cluster of related
terms, some meaning can be extracted. Let the machines do the
hard-work not the publishers.
-brian
--
brian suda
http://suda.co.uk
TSchultz55
I think what it boils down to is: does the overhead of enabling
semantic capabilities outweigh the benefits? This can be argued on
all day.
And again, this is an optional attribute that semantic-aware agents
could utilize. I guess the argument could also be made then that we
don't want to over-bloat the specification.....
> now we need to define what to expect (or types of things to expect) at that URI.
"uri" tag to store locations of semantic metadata and concepts. You
COULD specify an image, a word document, or even another webpage, but
I'm not sure where that would get someone however.
> The more layers of complexity the more we lose people.
to ignore the "uri" tag.
> you are basically asking each person to go find
> a URI that actually describes their interest and then putting that in
> their APML file manually - this can't really be done while compiling
> keys dynamically into APML.
list of relevant semantic documents that will support a key term (such
as "wine"). This is how I got the above URI for this example. This
process can in fact be automated
Web sites that implement APML with a specialized domain could also
find semantic metadata easily. So, for example, the site
TV.WINELIBRARY.COM (great site - shameless plug :)) could already have
knowledge of where to locate an appropriate set of semantic markup
documents and use them accordingly.
> --- i would agree, but i don´t think adding a URI gives much value
> because no one will do it.
> A way to solve this could be a <cluster> element.
> hard-work not the publishers.
manipulating terms without understanding their context. What about
something like:
<Cluster terms="alcohol,beverage,drink">
<Concept key="wine" ........../>
<Concept key="merlot" ......./>
....
</Cluster>
<Cluster terms="computer,linux">
<Concept key="WINE" ......../>
<Concept key="penguin" ...../>
....
</Cluster>
Thoughts? Great stuff all around.
Cheers!
Tim
Brian Suda
> > A way to solve this could be a <cluster> element.
> > .......
> > from a cluster of related terms, some meaning can be extracted. Let the machines do the
> > hard-work not the publishers.
>
> I do like this idea, however, we're still relying on simply using and
> manipulating terms without understanding their context.
--- true, but if both the parser and the read know that this was
gleaned from context, then both treat it the same, whereas i give you
a URI (right or wrong) gleaned from context, the APML reader might
assume it is EXACTLY what you mean, when it wasn't. That is the error
between what i intended (clusters) and the explict (the URI). The
clusters are slightly more robust because it allows for a wider range
of tolerances, whereas the URI is pretty strict with a single meaning.
> What about
> something like:
> <Cluster terms="alcohol,beverage,drink">
> <Concept key="wine" ........../>
> <Concept key="merlot" ......./>
> ....
> </Cluster>
i don't think there would need to be a terms attribute, everything in
the cluster is lumped together. So if i sent this to flickr, i want
pictures (to a certain value) of wine, like the drink and pictures of
wine like the OS. It knows this because it can look at the other terms
and match them to internal clusters in it's own DB based on its
millions of users rather than a URI somewhere which might go away or
be 404 or timeout.
> Thoughts? Great stuff all around.
--- clusters certainly have their problems too, how do you get a term
weight across clusters, etc. I just put that out there as an
alternative to URIs. Clusters are in use today on sites like flickr,
even amazon. All mined from user data, just like you attention data is
mined. To me clusters seem more natural, i was talking to my friends
in the US about football and helmets, and i talk to european friends
about football and pitches and back to my american friends about
pitches and baseball. Do i want to find 6 different URIs or just let
the "smart" attention engine figure out that when i am talking certain
words in certain contexts, they should remain in those contexts.
i'm not 100% how to solve this, but an ontology layer seems abit of
overkill to me. Maybe clusters can't solve the problem either, but at
some point we have to accept that there will be collisions and
ambiguities - that serendipity makes life fun.
Chris Saad
gdupont
To answer to everyone (withou any particular order) :
- uri attribute is optional as I proposed : the APML agent can use it
or not, and moreover should have backup strategies if the uri point
nowhere (or nothing understandable)
- agree on the fact that adding semantic could blast the APML by
adding to much complexity... But it does not mean that we should close
the semantic door. I only propose a way to add semantic but it rely on
the implementation to "really" make use of it.
- the cluster philosophy appears to be cool (at least a -easy - first
step on disambiguation) and that was something I wanted to introduce
(I'm stealing a good idea but finding link) through the rename of
"key" too "label". It is only a semantic issue (what is behind key)
but refer to the fact that a kay is assumed to be "unique" but a label
is by definition not unique... Whatever, key can be kept as a "master
label" and labels (or related terms) can be included to enlarge the
context of the key. It means something like :
<Concept key="wine" context="beverage, merlot" value="0.87"
updated="2007-07-13T09:22:00Z" />
updated="2007-02-11T04:21:00Z" />
simple.
- what is behind the uri is the big question... I could suggest only
well defined RDf or OWL ontology but I know your reaction and that
almost no one will do that (well, I will... try at least). But as I
already said, I don't think that ignoring the semantic "wave" (of the
web of data or whatever) is the right way. Moreover, by defining a new
"simple" format, you are defining "another format". As a developer,
I'm a bit bored by all those new revolutionary formats (no offence on
APML which is revolutionary !) whith only limited compatibility.
Having a (potential) link to my RDF resources I built when W3C
recommended it will simplify all my work.
No conclusion at all... But still interested in the discussion.
G.D.
gdupont
Addition of new node types - a number of new node types have been
proposed, specifically people and locations.
That's what I wanted to point out when speaking about format
compatibility... semantic web has already proposed many way to define
every concept you want. Why building a new one ? For the sake of
simplicity, I understand, but keep a "key" label, add simple context
and/or uri for well defined resources, but try to avoid to add new
types of nodes... Concept is simple ! Concept is clear !
G.D.
Elias Bizannes
I think both methods have merit, but I prefer URI's. I don't think it
adds complexity, because it's simply defining the concept in the
applications specific ontology which would need to happen for it to
have any value. Whether that ontology is public like a link to a
wordnet term, or a custom ontology for the application, I don't think
this matters. With everyone linking their concepts to different
ontologies, we allow the APML file to be flexible enough to
accommodate diverse terms as applications can create terms on the fly
perhaps. But the whole principle behind the semantic web is having
everything linked, and it will only be a matter of time when all these
ontologies get linked together. That aside, the principle concern
about APML is allowing a user to control their data; having other
applications use the data collected elsewhere is secondary.
I think the issue raised that pointing to a URI is not solving the
problem, isn't an issue, as an application determines the ontology it
links to. Merely having two different URI's for wine for example,
regardless of what is at the location, still derives meaning because
the application understands they are different concepts as they are
different URIs. If we don't use URI's, may I ask then, how does an
application understanding the meaning of the terms it generated? What
I am trying to get at, is that applications have an ontology
internally - the only difference is possibly making this public.
I think clustering is the weaker solution because it still involves
some type of guesswork. Having said that though, I think its powerful
and I like the idea - but for this specific issue, I think URI's are a
much more superior way of archiving the aim. I was going to suggest we
still incorporate it, but for the sake of simplicity, maybe leave it
out
On Nodes
Why not? Location is another dimension of attention that you can't
ignore. Imagine triggering concepts based on your coordinates, rather
than the profile "work" and "home. People I am willing to cede because
it can be a bit mroe difficult to differentiate a persons name from a
non human noun. Having all nouns as concept makes it easier.