+cc: Libby
On 21/5/09 03:27, Renato Iannella wrote:
On 19 May 2009, at 19:09, Dan Brickley wrote:
But I don't want people to have to use two vocabs for saying pretty
basic things.
Is "foaf:myersBriggs" a pretty basic thing?
Ah, I was not clear. I wasn't saying that these 2 vocabularies vCard and
FOAF were "just for simple things". But that too many (for my taste)
common descriptive tasks currently neccesitate the use of two or more
RDF namespaces.
We made this mistake with RSS 1.0, allowing the possibility of
modularisation to encourage us to over-modularise.
If you want an exact 1:1 representation of vCard, then the
vcard-in-rdf docs are your best bet. If you want any of the semi-random
mischief in the FOAF spec, you should also be able to mention an address
without needing a 2nd namespace...
Much, is not all, of the "FOAF Basics" [1] is a repeat of vCard semantics.
At the time I'd been working more with WHOIS++
(http://www.ietf.org/rfc/rfc1835.txt), which was a distributed directory
system for people descriptions. The FOAF schema of course overlapped
with that. It also overlapped with the content of the MCF submission to
W3C, which was the origin of the RDF specs -
http://www.w3.org/TR/NOTE-MCF-XML-970624/#secA.2.1 ...and it overlapped
with the discussions in the Dublin Core community about an RDF
representation for qualifiers of the DC agent properties -
http://dublincore.org/2000/03/13-dcagent - FOAF overlapped with all this.
And yes there was overlap with vCard, and with SHOE from Jim Hendler's
group, and countless other schemas. There is today also overlap with
large RDF vocabs that do try to describe everything, eg. Cyc, Freebase,
and Dbpedia could probably handle 95%+ of anything in vCard and most of
FOAF too (although as you point out, FOAF has some distinctive
properties, quirky or otherwise).
But if you did not want a second namespace, then reusing ontologies is a
lost cause!
That isn't so and doesn't follow. Many usage scenarios reasonably
require several, even dozens of namespaces. Cultural Heritage work for
example, or even backing up your Flickr photo metadata: see
http://cpansearch.perl.org/src/ASCOPE/Net-Flickr-Backup-2.991/README for
a nice example that uses fourteen (14!) namespaces perfectly well.
All I'm saying is that there are significant cases where using two
namespaces for some small mention of a Person and eg. their address is
overkill, is in deployment practice known to be a major retarding factor
and risks turning people away from RDF/RDFa at all. And that to my mind
(after having watched RSS1 die a slow and horrible death) is a reason to
make sure some common addressbook scenarios are covered by the FOAF case.
I thought the Semantic Web / Linked Data was all about this ;-)
There will always be multiple ways to say things; this is healthy. RDF
is like Perl in that regard. But without commonly understood idioms that
won't be dismissed as overly complex, we face an uphill struggle.
Now FOAF will always do a theoretically "worse" job than something on
its peripherary. For example, we might in FOAF be able to say where you
work, and even when you worked somewhere. A custom CVs and Resumes
vocabulary will be able to say exactly what your role was in different
parts of different institutions at different times, and perhaps also who
your line manager was, or how much you were paid, or link to
testimonials for any of those roles. In FOAF it's conceivable we might
add the bare basics of family tree stuff. But a custom geneology
vocabulary could express the vast complexity found in geneological
research data, which is essentially a historical investigation involving
representations of uncertainty, reification-like mechanisms, plus
notions of brother/sister/cousin/uncle that will need reworking for each
cultural context the Web touches. Another big job. In FOAF we can say
crudely where someone is "based near", and the W3C SWIG "basic Geo"
vocabulary picks up where we leave off and handles lat/long positioning
info. Other geographic representations go much further in that direction
than either FOAF or vCard, handling notions of city, village, places,
their identifiers, inter-relations, alternative names, and associated
statistical information.
Further - and I'm getting to my point - in FOAF now we don't have a way
of saying what language someone speaks, but there is Inkel's
speaks/reads/writes vocabulary that allows you to say a little about
which languages you speak, read, or write. His vocabulary doesn't let
you say anything currently about how well you can speak, read or write a
language, just that you do. And in FOAF we have the basics for
describing your interests. To do this we can talk about a page or a
thing that indicates your interest, and we therefore allow the indirect
application of dc:subject and SKOS concepts to say what *exactly* you're
interested in. Any SKOS scheme at all can be used this way, and it was
right and proper that the development of SKOS was done outside FOAF
because it was a huge job to do properly, even if both vocabularies had
the same origins. So --- now we have SKOS for describing topics, and in
2009 we have lots of data sources coming online for describing those
topics in RDF/SKOS, using thesauri and even rich classification systems,
we can revisit FOAF's treatment of interests. And also skills. Since we
can now use SKOS to talk about the topic "Decline of Tin Mining in
Sweden, 1918-1939" we should be able to re-use that in FOAF not only to
describe someone's *interests* but also their *expertise*. If I am
somehow a world-renowned expert on the Decline of Tin Mining in Sweden
between the wars, it should be possible to describe this in machine form
such that I can easily be found. There are expert-finding projects
around FOAF trying to do just this.
OK so imagine we were to add "expertise" in FOAF and a construct that
used decentralised SKOS subject codes (eg. library of congress, dbpedia,
udc etc) to indicate the precise subjects with URIs that de-reference to
RDFa/SKOS. Now that would be quite cool, but it wouldn't take long
before someone someone says "OK, but how do I express the extent of my
expertise about Tin Mining?", "how do I make it clear that I am a world
guru about Copper Mining but only know the basics about Uranium
Mining?". Now I'm confident we can fix up the SKOS side of this such
that we can cluster related expertise together, ie. make it possible to
find all people with skills relating to digging metallic substances out
of the ground. And that's actually a pretty fabulous place for the
machine readable Web to have arrived at. But if we want to add any vocab
for expertise *levels* into the FOAF construct, note that it won't
directly apply to the vocabulary I mentioned above that Inkel created in
2001 or so. Which is OK but it's a cause for a conversation with Inkel
and others about how this older construction for talking about language
skills relates to some newer general structure for talking about all
other kinds of skills. If we don't work out those issues, then
developers will say "why can I say I'm super-expert at Tin Mining, a
blushing beginner at Copper Mining, yet I'm only able to say yes or no
to whether I speak Dutch". We need better answers for developers than
"that's just the way it is".
This I hope illustrates some of the practical awkwardnesses of growing
this thing organically over time, but also why we're all doing pretty
find. The overlaps are inevitable, but as long as we are all clear about
where each project is going, I hope we can minimise the impact off
organic growth and representational redundancy on end users and developers.
I can't predict exactly which areas will in the future get a more direct
treatment within FOAF's core namespace, versus use-by-inclusion from
other vocabularies. I think our history in the project does show I'm a
big supporter of a multi-namespace world, and wherever there are
overlaps between what can be expressed in FOAF and other RDF idioms I'll
do my best to make sure the human and machine documentation indicates
the other options, without confusing developers too much. FOAF by design
does a partial job in many areas, since describing people is a
never-ending task.
Hope this helps make some direction clearer...
all the best,
Dan
Cheers... Renato Iannella
NICTA
[1] http://xmlns.com/foaf/spec/
