online accounts vs IM accounts? was Re: indicating meta and type?

[Bill Kearney]

> From: Dan Brickley <danbri at w...>
>
> Here's a question, that's pretty independent of RDF syntax details:
>
> If we're making up a way of representing user accounts for online chat
> services (AIM, MSN, iChat etc. Instant Messaging), is that problem any
> more specific than the general one of representing a user account with
> online services in general (eg. Slashdot, eBay, Amazon, etc. logins).

I'd go along with there being a similar need. This is sort of why I'd
envisioned using an attribute for the service URI. That way anything wanting to
have a foaf 'service identity' would need do nothing more than make up the URI.
It would then become dependent on the client programs consuming the foaf to make
the association.

<foaf:meta type="http://messenger.hotmail.com" rdf:value="joeuser at m..."/>
<foaf:meta type="http://slashdot.org" rdf:value="joeuser666" >
<foaf:meta type="http://oscar.aol.com" rdf:value="joeuser39423" />

etc, with the expectation that anything looking to see if a user has an MSN
messenger account would have to look for it's type URI. This is undoubtedly
duplicating the same sort of thing a MIME type pretends to accomplish. Unless
something knows what to look for these meta elements could be ignored.

> My suggestion would be to take two parallel strands:
> (i) create nice simple shortcut properties for all the main IM services,
> foaf:aimChat_nick, foaf:msnChat_nick etc.,

I would *really* like to avoid this. There are WAY too many different online
services to make this feasible. AIM, Yahoo, Jabber (on any number of servers),
IRC, ICQ, MSN, SMS (on any number of telco systems), Alpha pagers, Blackberry
devices, etc, ad infinitum.

> as well (ii) as a more general if
> verbose representation of a generic user account. The former is a
> convenient user-friendly shortcut; the later is for backend/script use,
> and for purists. Both have a role.

I don't see the use of one vs the other as a purist versus convenience argument.
That type URI could just as well be "AIM", "MSN" or whatever. The value being
it would also be possible to anyone to 'invent' a new sort of element that could
be useful within the foaf context without extending the schema or using an
entirely different one.

> This tradeoff between verbose/expressive and short/sweet/cludgy is
> of course a classic design headache, and one that we'll run into with
> FOAF and RDF/SW apps time and time again.

Quite possibly when you want to have this become an entire /container/ of other
account-related bits of info. I'm not entirely clear on how to construct that
RDF-wise. I suppose to use an external, possibly encrypted, file you'd use:

<foaf:meta type="http://bankofamerica.com"
rdf:resource="http://localhost:8080/usb/keychain/myaccount.xml" />

Or something to that effect.

> ...here we see the tradeoff between saying 'person X went to a school, S
> that has a homepage SP' and 'person X has a schoolHomepage of SP'. The
> two forms have strengths and weaknesses. As with IM, I think we need to allow
> for both forms, and there will be a need both for tools that map the one
> into the other, as well as user documentation that explains which is the
> preferred form in some context (eg. "use foaf:schoolHomepage in your foaf.rdf;
> use the longer form if you're describing the details of each school...").

Hmmm, not sure the account storage/school homepage example is a good analogy.
But I follow your point. I'm not sure that, in the context of a foaf document
that it'd ever need to make statements about the SERVICE. I suppose I'd also
argue that a foaf file, for a person, has little need to ever indicate the
school of a person. This is "friend of a friend" not "curriculum vitae of a
friend". Seeing this analogy raises the concerns about it being more of an
academic experiment instead of a real-world solution; a sympton seen on WAY too
many net-related things. Granted, solutions are developed to solve needs so
it's not like academic institutions aren't going to create academic solutions.
Foaf, however, does seem to have larger and more immediate value in circles much
wider than just academia. </soapbox...>

So what would be "bad" about coming up with a generic meta element? What's "not
good" about it?

-Bill Kearney