[rdfweb-dev] Scalable Interfaces - for searching through tons of humans...

Sun Jan 4 17:44:28 UTC 2004

I really think the solution to scaling interfaces for people aggregators
(whether they be from RSS feeds, spiders or some sort of auto-discovery
code) - is to build Facewall interfaces - with traditional search
criteria kind of controls.

We're gonna do something sexy this quarter - but here's a naïve mockup
of what that might look like.

:-)

http://blogs.it/0100198/CommonsSearch.jpg

The idea is that as search criteria changed, the sorted list of faces
would alter - in front of your eyes.  It's all about the faces - baby!

- Marc

-----Original Message-----
From: rdfweb-dev-bounces at vapours.rdfweb.org
[mailto:rdfweb-dev-bounces at vapours.rdfweb.org] On Behalf Of Danny Ayers
Sent: Sunday, January 04, 2004 9:06 AM
To: Morten Frederiksen; rdfweb-dev at vapours.rdfweb.org
Subject: RE: [rdfweb-dev] Range/domain of foaf:knows and subscriptions

> I intended to claim that we shouldn't extend foaf:knows to that
> level, but

...

> So widening it to foaf:Agent is fine with me.

Heh, yep, I think I saw it as better tighter not long ago. I suspect
there's
some rule at work here - foaf:knows (and its predecessors) are a key
building block, more people will use it, more people will bend (/break)
this
part of the spec in their implementations, the less constraint seems
feasible in the spec v 1.1. Something like that.

> > (btw, according the schema in the spec that mbox_sha1sum has a
domain of
> > Agent, whereas mbox doesn't have any constraints - is this
> intentional or
> > work-in-progress side effects?)
> I think that's a typo (can something missing be a typo?), since the
spec
> prose for foaf:mbox does say that its domain is foaf:Agent.

Ok, one for the bugtracker (wherever it is? - Google seems to have
forgotten).

> > What might be useful is to have (in an appropriate namespace) a
property
> > something like "blogrolls"
> Yep, we've discussed subscriptions and the like before [1] [2],
> and with the
> recent actions in OPML-land, it'd be nice to get this sorted out.

Dude, I totally didn't make the connection between subscriptions and
blogrolls this time round...

> The primary usecases seem to be avoiding crossposts [1], whitelisting
and
> perhaps finding suggested reading or people with similar
> interests, with the
> presumption of a subscriber reading everything the primary issue.

Yep, for RSS-style subscriptions at least I reckon there's an immediate
need
for filtering mechanisms. Anecdotal evidence suggests that the current
generation of newsreaders make it hard to manage/keep up with > 200 or
so
subscriptions. I'm willing to bet that if you filtered the blogosphere
for
"all the blogs that post something that interests me/you/him/her at
least
once a week", you'd be well into the 1000's.

> One can subscribe to RSS channels (almost equivalent to blogrolls),
news
> groups, mailing lists, news letters (another mailing list?), news
> papers and
> magazines, book clubs, more? These "subscription targets" have
differing
> identifying properties, so shouldn't be grouped too much.

Hmm, yes, it could get messy otherwise.

> > you could also have
> > Harry x:blogrolls BBC News
>
> A x:blogrolls property with a domain of foaf:Agent and a range of
> foaf:Document (which would ideally be a foaf:weblog of something)
> seems nice.

> However, then there's the difference between blogrolls and aggregator
> subscription list (like OCS [3]). It seems clear that the object of
> x:blogrolls should not be an RSS channel, but then we need a new
> property for
> that.

Yep, I agree there needs to be some way of telling them apart, though
there's nothing very fine-grained in the specs:

[[
The foaf:Document class represents those things which are, broadly
conceived, 'documents'.
]]

So what if we do say:

{Agent} blogrolls http://bbc.co.uk/feed.rdf

(blogrolls = "this Agent's blogroll includes")

is feed.rdf still a foaf:Document? Probably...but that doesn't help see
the
difference from :

{Agent} blogrolls http://bbc.co.uk/index.html

> x:aggregates, with a domain of foaf:Agent and a range of
> rss:channel, could
> be used, but that's just one ugly property name, and seems to
> imply something
> else...

Right, that is pug-ugly. Unfortunately the RSS 1.0 spec for <channel>
doesn't help much either:

[[
...The {resource} URL of the channel element's rdf:about attribute must
be
unique with respect to any other rdf:about attributes in the RSS
document
and is a URI which identifies the channel. Most commonly, this is either
the
URL of the homepage being described or a URL where the RSS file can be
found.
]]

Given that folks are using rdf:seeAlso to point to other RDF files,
perhaps
that could be used as a hint? If so, maybe add a parallel seeAlso
property
somewhere??

{Agent} blogrolls http://bbc.co.uk/feed.rdf
{Agent} seeAlso http://bbc.co.uk/feed.rdf

errrrrrrrrrrrrrm ok, maybe not. What about adding another property on
the
target this way:

http://bbc.co.uk/feed.rdf rdf:type rss:channel

?

> A mailing list could be said to be just another agent, with the
various
> properties that apply, plus some additional ones like the various
> administration addresses (kind of seems like an
> OnlineAccountService as well).

That's an interesting approach, seems to make sense, I'll have to mull
it
one over a bit..

> For this, an x:subscribesTo property would be possible, with a domain
of
> foaf:Agent and range of foaf:Agent (or a new
foaf:OnlineAccountService,
> subClassOf foaf:Agent, tying it to the property
> foaf:onlineAccountServiceHomepage).
> The same seems to hold for news letters, essentially the same as
> a mailing
> list, but also a lot like an OnlineAccount without (?) an accountName.
>
> For news groups, it seems like either a completely new class should be
> defined, or that a property should simply always (not possible to
> restrict)
> point to a news: URI.
>
> I think it seems it'll be too much trouble finding differing
> properties for
> different "subscription targets".
>
> I think a single property, x:subscribesTo (domain: foaf:Agent, range
> rdfs:Resource), could work, provided that classes for the various
> types of
> "subscription targets" are created - the information on the type
> of resource
> referenced could then come from somewhere else:
> For blogrolling, the range would be a foaf:Document or an
> rss:channel (thus
> avoiding the issue of having to differentiate between the two, a
> good thing
> for easy generation from OPML etc.), automagically infered by an agent
> publishing an RSS channel or declaring his/her homepage
> For mailing lists and news letters, the range would be a
> foaf:Agent (possibly
> subclassed to x:MailingList).
> For news groups the range would be an x:NewsGroup.

Right, I like the nice minimal x:subscribesTo property to start from. It
may
also be possible to use OWL restrictions - e.g. if the subscriber is a
Person, the object is a Document (a blog), if the subscriber is a
non-human
Agent then the object is a channel (a feed).

Eek! Just looking at non-person agents - I think you'd need to say the
union
of the class Agent with the complement of the class person...assuming of
course that these operators make any sense at all with rdfs:Class...

Maybe we need foaf:Bot subClass foaf:Agent

(At this point you insert links to where we discussed this before... ;-)

> The next step would be to create a namespace for these kinds of
> subscriptions, with various properties indicating level of
subscription:
> reads:always
> reads:regularly
> reads:sometimes
> reads:onOccasion
> Perhaps even also the corresponding writes, where that applies
> (news groups
> and mailing lists, providing some further restrictions that can
> be learned
> from)...

writes=rights?
Anyhow, yes, that looks enough to be useful without being too complex to
implement.

Cheers,
Danny.

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev at vapours.rdfweb.org
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev