[rdfweb-dev] Serious question about silly attributes

[Dan Brickley]

[snip]

Good questions, all.

Here's my take. If marketing is about convincing people the need things
they didn't previously realise they needed, FOAF is Semantic Web
marketing. Aside: FOAF itself has not been marketed to date, on purpose,
because it has many characteristics that suggest a risk of a scary 
network effect adoption curve, and we're not ready for that. But for
those who have found their way to FOAF, it often serves as an apetizer
for Semantic Web. Whether some particular term is 'in' or 'out' of FOAF 
doesn't ultimately matter, because the FOAF design allows others to 
fill the gaps.

Before FOAF, people didn't realise they wanted an RDF/XML way of 
representing wednesday codes, hot-or-not image ratings, food preferences 
or karma cred. Obviously we can't put it all in FOAF, or even in 
accompanying vocabs created by FOAF developers. But we can put enough 
in to show the way it works, and to get people asking "hey, if you can 
say xyz in FOAF, why can't you say ...?". This creates demand for new 
RDF vocabulary. 

Now we could have omitted everything in the expectation of supporting 
vocabularies covering all the fun extensions, but without a few 
somewhat arbitrarily extended properties, it wouldn't be clear to enough 
people that the technology can work this way.

Lately I've been working on the core FOAF spec. When that's in a more
respectable form, it will be time to document more clearly how someone 
would go about creating their own RDF extensions to work with FOAF.
Already there are a few of these (see links at end of 
http://rdfweb.org/topic/FoafVocab) but the process could be much better
documented (eg. we have a lot to learn from the RSS 1.0 Extension
Modules experience here). I think the priority has to be to get the main
FOAF spec out first, shortly followed by some HOWTO for extending it in 
separate namespaces.


The specific topics you mention, extensions that involve qualifying 
online account info, are possible but are a bit subtle to get right.

Here are some design sketches:

(i) we show how AOL, Microsoft etc could each define a handy convenience
property named after their service/database, eg.

<foaf:Person xmlns:ms="http://microsoft.example.com/chat#">
  <foaf:name>Dan Brickley</foaf:name>
  <ms:msnChat>danbri_2002</ms:msnChat>
</foaf:Person>

Further, we would specify additional markup that they could include in
the schema at http://microsoft.example.com/chat# which would say a bit 
more about the property, the database it applies to, and suchlike. AIM,
ICQ etc could all do the same.

Strengths:

 - very decentralised
 - doesn't privilege the 80% of dominant services by naming them within 
   the core FOAF vocab
 - the end user markup is concise, simple


Weakness:
 - requires a separate RDF vocab to be set up for each database
 - requires end users (and tools) to remember to include the rightnamespace
   declaration for each property used
 
(ii) 
a related design pushes all the variable content down into instance
data, so only one vocab needed.

<foaf:Person rdf:nodeID="p1">
 <foaf:name>Dan Brickley</foaf:name>
</foaf:Person>

<foaf:OnlineAccount>
  <foaf:accountUser rdf:nodeID="p1"/>
  <foaf:accountType>Chat</foaf:accountType>
  <foaf:accountServiceHomepage rdf:resource="http://chat.msn.com/"/>
  <foaf:accountName>danbri_2002</foaf:accountName>
</foaf:OnlineAccount>


<foaf:OnlineAccount>
  <foaf:accountUser rdf:nodeID="p1"/>
  <foaf:accountType>Ecommerce</foaf:accountType>
  <foaf:accountServiceHomepage rdf:resource="http://www.amazon.com/"/>
  <foaf:accountName>danbri at rdfweb.org</foaf:accountName>
</foaf:OnlineAccount>

<foaf:OnlineAccount>
  <foaf:accountUser rdf:nodeID="p1"/>
  <foaf:accountType>DiscussionBoard</foaf:accountType>
  <foaf:accountServiceHomepage rdf:resource="http://www.slashdot.org/"/>
  <foaf:accountName>danbri</foaf:accountName>
</foaf:OnlineAccount>

<foaf:OnlineAccount>
  <foaf:accountUser rdf:nodeID="p1"/>
  <foaf:accountType>OnlineGaming</accountType>
  <foaf:accountServiceHomepage rdf:resource="http://www.microsoft.com/xbox/"/>
  <foaf:accountName>ban dr i</foaf:accountName>
</foaf:OnlineAccount>

Strengths:
 - generic, extensible
 - vocab makes no commitments regarding any particular services
 Weaknesses:
 - verbose
 - not something to get wrong; representing this info is important and 
   has some subtleties.
 - the design of accountType could be done in a couple of ways (rdf:type
   vs controlled list of strings), both with downsides (and upsides :)

Apart from the first eg, these are all real accounts. I keep my online banking
info in a similar format, PGP-hidden on my hard drive. Some variation of
this will work. This is not something we should goof around with
casually; when the FOAF spec is in a more professional form, then
dealing with online accounts is high up the todo list. In the meantime,
we have some shorthand properties for dealing with certain chat
accounts. Those give us a flavour of what a general approach could
achieve. Note from the above markup you could tie together my behaviour
in online gaming (Xbox) with my rantings on Slashdot, my purchases on
Amazon and any other information you have on me via FOAF. This is
dangerous stuff...


(iii) tie these together...
We can write rules for mapping between this verbose, expressive form and 
the shorter, single-property versions (eg. slash:slashdotID,
am:amazonName or whatever). So our investment in the convenience
shorthand chatIDs currently in FOAF shoulddn't become too big a burden.





To recap this into a roadmap:


(i) FOAF spec rewrite (in progress)
(ii) Improve documentation for 'how to make your own vocab'
(iii) Explore vocab for generic OnlineAccount
(v) fix in light of implementation feedback, court cases etc...


--danbri