FOAF and "overlaps"

+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/
>
>

Received on Thursday, 21 May 2009 10:22:31 UTC