[rdfweb-dev] Serious question about silly attributes
danbri at w3.org
Sat Jul 26 16:07:49 UTC 2003
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
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
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.
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.
- 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
- 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
a related design pushes all the variable content down into instance
data, so only one vocab needed.
<foaf:accountName>danbri at rdfweb.org</foaf:accountName>
<foaf:accountName>ban dr i</foaf:accountName>
- generic, extensible
- vocab makes no commitments regarding any particular services
- 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
(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...
More information about the foaf-dev