Revision as of 01:35, 1 November 2007 by Admin (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)



Current status: open Owner: danbri at (from IssueTracker page)

This is a FoafVocab issue, documented as such by linking it from the IssueTracker page.

Issue description - rdfweb-dev mail from danbri: foaf:chat sub-properties could be better described

<danbri> We were discussing the kinds of things which properties such as foaf:msnChatID can apply to... It was tempting to say foaf:Person, however bots, scripts and other software artifacts can have chat IDs...

<kota> what about chatID, simply?

<danbri> foaf:nick serves that purpose, largely

<danbri> but without scoping a chat ID to a particular controlled set of names, you lose a lot of power

<kota> hmm

<kota> i see

<danbri> If I say 'there is a person and they have a chat id of danbri_2002' that doesn't unambiguously identify anything for sure.

<danbri> If I say 'there is a person with a foaf:aimChatID of 'danbri_2002', that picks out... me.

<danbri> ...which is good foaf, as it makes yet another way of merging data together...

IRC chat 2003-07-06, quoted in rdfweb-de issue archives

What is their domain? range? Are they owl:InverseFunctionalProperty?

There are some possible variations here.

Jabber IDs get used for all sorts of things. There is also a Jabber URI scheme we should look at.

The others, it is tempting to say they have an rdfs:domain of Person. However we often see IM accounts for bots and other non-humans.

This suggests that an Agent class may be appropriate. (MCF had this btw). bug description on rdfweb-dev issue archive

When an issue is resolved or its status w.r.t. the FOAF spec changes, that changed state of affairs should be documented somewhere less transient than the wiki. See IssueTracker for more notes on issue management conventions.