Re: [foaf-dev] New FOAF properties

Dan,
That was very detailed and very helpful. Thanks.
IMHO, I think we do need something for expressing resume type information. 
It is good to have a foaf:interest but one also likes to express one's 
skills.  I agree with what Bob was saying about CV that the skills, 
experience and etc. should be related to a foaf:Person.  A person has 
certain skills and experience, not the document about them.
I found DOAC - description of a career but that wasn't used too often either 
and was a bit awkward.
The only other thing I was thinking about on the foaf:interest is that a 
dc:title should be included to provide a readable result for SPARQL queries. 
Many profiles, that I've seen do use the dc:title attribute, though.
I don't know why CV references FOAF at the bottom of it's description page 
but does not ever use any foaf classes or properties.

I was reading a recent book on SPARQL and the author uses foaf often for an 
address book.  I guess that is a good idea for using foaf.  I thought it 
would be helpful to keep track of all the different places where I have 
accounts, blogs, wikis, etc. etc.
Bruce

-----Original Message----- 
From: Dan Brickley
Sent: Tuesday, September 06, 2011 7:28 AM
To: Bruce Whealton
Cc: [email protected]
Subject: Re: [foaf-dev] New FOAF properties

On 6 September 2011 12:28, Bruce Whealton <[email protected]> wrote:
> Hello,
>           I was looking at how some folks are using FOAF on Semantic
> MediaWiki sites and found some properties that are not on the spec, even
> listed as experimental or testing.  Some others I've seen but I'm unclear 
> in
> reading the spec how to use the class or property.

Sorry that this is confusing.

> We have class foaf:Image which is used with thumbnail, depiction or img.
> So, which should one use, img, or depiction or thumbnail?  I can see the
> difference between thumbnail and the other two but I'm not sure when to 
> use
> img versus depiction.

The foaf:depiction relationship (and its 'depicts' inverse) is more
general, and holds between any pair of things where oneis an image of
the other. By contrast, foaf:img is more like the relationship that
holds between you and a photo you put in a homepage or blog or online
profile.

We tried to describe this in the spec, some excerpts here. In general,
there is more documentation per-term in the FOAF spec than you'll find
in the raw RDF schema.

http://xmlns.com/foaf/spec/#term_depiction

"The depiction property is a super-property of the more specific
property img, which is used more sparingly. You stand in a depiction
relation to any Image that depicts you, whereas img is typically used
to indicate a few images that are particularly representative."

http://xmlns.com/foaf/spec/#term_img

"image - An image that can be used to represent some thing (ie. those
depictions which are particularly representative of something, eg.
one's photo on a homepage). "

"The img property relates a Person to a Image that represents them.
Unlike its super-property depiction, we only use img when an image is
particularly representative of some person. The analogy is with the
image(s) that might appear on someone's homepage, rather than happen
to appear somewhere in their photo album. Unlike the more general
depiction property (and its inverse, depicts), the img property is
only used with representations of people (ie. instances of Person)."
[...]


> Oh, and there is also logo which I guess would be more related to a 
> business.

Yup, or projects, organizations etc. There might be usage via DOAP
vocab for software projects.

>         Next with the deprecation of holdsAccount and it being replaced

(I prefer 'archaic' to 'deprecated'; we don't remove old things, just
change their documentation)

> with account.  Can someone demonstrate the structure of how this would be
> used with a facebook  or delicious account - presenting it in RDF/XML. 
> For
> example, I have the following for my delicious account.
> <foaf:holdsAccount>
>  <foaf:OnlineAccount>
>     <foaf:accountServiceHomepage rdf:resource="http://del.icio.us"/>
>     <foaf:accountName>brucewhealton2</foaf:accountName>
>
>  </foaf:OnlineAccount>
> </foaf:holdsAccount>
> To change that to use <foaf:account> do I just remove foaf:holdsAccount 
> and
> foaf:OnlineAccount, and nest the next two lines inside <foaf:account> like
> this:
> <foaf:account>
> <foaf:accountServiceHomepage rdf:resource="http://del.icio.us"/>
> <foaf:accountName>brucewhealton2</foaf:accountName>
> </foaf:account>

This is indeed not well documented, since it involved a second
decision: to use URIs of those service-based profile pages as the URIs
of the accounts. Not everyone was keen on this, but it seems to be the
way to go, especially given RDFa-style notations. So...

<Person>
<!-- etc etc -->
<foaf:account rdf:resource="http://del.icio.us/brucewhealton2"/>
</Person>


> Continuing... foaf:Class, I don't see that.

FOAF doesn't have a term called 'Class'. Where did you see this?

> foaf:interest and foaf:topic_interest - what’s the difference?

This is somewhat awkward territory. Basic idea was that we wanted to
encourage use of well-known URIs wherever possible. And (especially
ten years ago) it was much easier to find well-known URIs for
topic-indicating pages, than for "the topics themselves". So for
example, if I want to express an interest in the topic of XML, ...
what URI would I use?

There are a few candidates, but independent parties would probably
arrive at http://www.w3.org/XML/ fairly often. So the foaf:interest
term lets you use that directly. Or you might use
http://en.wikipedia.org/wiki/XML ... or both.

<Person>
<!-- ... -->
<foaf:interest rdf:resource="http://www.w3.org/XML/"/>
<foaf:interest rdf:resource="http://en.wikipedia.org/wiki/XML"/>
</Person>

This design expresses interests indirectly, via pages that are about that 
topic.

Now there are two trends that interfere here. One is that as linked
RDF data in the Web has grown, we have more direct URIs for the things
of interest (the other is SKOS, see below). So DBpedia for example has
a URI for the thing that is XML.

So topic_interest allows us to write that directly, if we prefer:

<Person>
<!-- ... -->
<foaf:topic_interest rdf:resource="http://dbpedia.org/resource/XML"/>
</Person>

...without confusing the page and the thing that the page is about.

FOAF has terms to talk about those relationships: for the strongest
case, we have foaf:primaryTopic (and an inverse, isPrimaryTopicOf).
And for weaker topical associations, foaf:topic (and an inverse,
foaf:page).

I made a diagram of much of this a while back, 'the topic topic'. See
http://www.flickr.com/photos/danbri/3282565132/

In that diagram there is a relationship called 'it', which is now
called foaf:focus. This addresses the third way of talking about
topics, which is by treating them as "things in themselves". The W3C
SKOS vocabulary, a close cousin of FOAF, does just this. And now many
libraries and other organizations publish lists of topics in RDF/SKOS,
based around the class skos:Concept. So in that tradition you will
often find more subtle distinctions between topics. Now, while the
dominant use of SKOS is for bibliographic description, describing
books and pages, ... it can also be used to describe people -- their
interest, expertise etc., and serve as a way of bridging between
descriptions of people (and organizations, ...), to descriptions of
content (books, docs, ...).

So foaf:focus describes a link from a skos:Concept to 'the thing
itself'. Not every SKOS concept (in a thesauri of classification
scheme) will have such a direct "thing", but many do, especially
concepts for people and places.

Focus is described at http://xmlns.com/foaf/spec/#term_focus

If you go to http://id.loc.gov/ you can find SKOS for the Library of
Congress subject headings.

At http://id.loc.gov/authorities/subjects/sh97007825 you can find a
description of their concept of XML (with a few related topics
nearby). Well it seems they have some server trouble today, but I have
a downloaded copy too. They use a URI based on that page to describe
it further and link it to other concepts:

<http://id.loc.gov/authorities/sh95002796#concept>
<http://www.w3.org/2004/02/skos/core#narrower>
<http://id.loc.gov/authorities/sh97007825#concept>.

Ok, so let's go back to where we started, ... and perhaps the approach
might start to make sense.


Here is a person 'Eric Example' whose interests are characterised
indirectly with relationship to pages about XML.

<Person>
<name>Eric Example</name>
<foaf:interest rdf:resource="http://www.w3.org/XML/"/>
<foaf:interest rdf:resource="http://en.wikipedia.org/wiki/XML"/>
</Person>

Now, what if those pages are themselves described using Dublin Core and 
SKOS?

We could write this as either:
(1)
<Person>
<name>Eric Example</name>
<foaf:interest rdf:resource="http://www.w3.org/XML/"/>
</Person>
<Document rdf:about="http://www.w3.org/XML/">
   <dcterms:subject
rdf:resource="http://id.loc.gov/authorities/sh95002796#concept"/>
</Document>

Or we can fold the two together, ie.

(2)
<Person>
<name>Eric Example</name>
<foaf:interest>
  <Document rdf:about="http://www.w3.org/XML/">
   <dcterms:subject
rdf:resource="http://id.loc.gov/authorities/sh95002796#concept"/>
</Document>
</foaf:interest>
</Person>

This directly engages with the bibliographic perspective on describing
topics/subjects, and means we could exploit information from Library
of Congress to find this person.  For example the narrower concept in
LCSH, 'sh95002796', 'Document Markup Languages' could be used to link
to other people or documents.

So, to close the loop, we'd like a name for the relationship between
the abstract concept of "XML", where the subject code is the thing,
'http://id.loc.gov/authorities/sh95002796#concept' to the notion of
'the thing XML', i.e. http://dbpedia.org/resource/XML ... ....and
foaf:focus is used there.


Natural question at this point: "IS THIS TOO COMPLICATED?"

Yes and no. Some things are given and beyond our control: there *will*
be lots of different Web identifiers that we can use to characterise
topics (of expertise, of interest, of books/pages). Some of those IDs
will be for content items, some from wikis, some from lists of
categories, keywords, from thesauri. We don't have much choice but to
try to integrate across them, rather than impose a single 'simpler'
solution. And in some contexts having careful names for all these
inter-relations is very important.

Now back down at the level of simple user profiles, I think we have
different concerns.

Should we need really to carefully distinguish

* http://en.wikipedia.org/wiki/XML (a document about XML)
* http://dbpedia.org/resource/XML (XML itself)
* http://id.loc.gov/authorities/sh95002796#concept (the concept of XML)

...when publishing a simple FOAF user profile that lists interests?

(and I didn't even mention http://www.w3.org/XML/ or
http://dbpedia.org/page/XML or
http://id.loc.gov/authorities/sh95002796 ...)

My instinct is: no

We should consider making foaf:interest vaguer, such that any of those
three are acceptable. Publishers aren't going to go looking up obscure
distinctions between foaf:interest and foaf:topic_interest and that
other pattern using SKOS ... they just want to mark that this is a
relationship between someone and a URI characterising one of their
interests.

So I suggest we become more tolerant about the URIs acceptable as
values of foaf:interest such that I could write

<Person>
<name>Dan Brickley</name>
<interest rdf:resource="http://en.wikipedia.org/wiki/XML"/>
<interest rdf:resource="http://dbpedia.org/resource/XML/">
<interest rdf:resource="http://id.loc.gov/authorities/sh95002796#concept"/>
</Person>

...rather than use 3 different flavours of link. This does introduce
some fuzzyness, particularly when describing the interests of
librarians and subject classifiers, but I think that is bearable.

Another point re 'is it too complicated': FOAF is just a dictionary of
terms, to be used to make simple RDF factual claims. Other conventions
are needed to get strong interop, just as in natural language.

> foaf:made versus foaf:webpage, foaf:weblog, and it's use with 
> foaf:Project?
> surname vs family_name?

foaf:made is general, and equivalent (in reverse) to dcterms:creator
(and foaf:maker).

foaf:webpage doesn't exist.

'surname' and 'family_name' are archaic; 'familyName' is current.

> That should be it.

Phew :)

> Has anyone used the cv vocabulary for resumes?  It is interesting that it
> doesn't setup a cv or resume as a property of the person.  So, while the
> vocab has a reference to foaf, there is no statement about how to match up 
> a
> foaf:Person with a CV.

There have been various efforts in that direction, but nothing that
seems generally considered conclusive.

The rise of SKOS as a way of talking about subject areas means (imho)
that any coverage of CVs ought to allow for SKOS-based description of
topic areas.

hope this helps,

Dan 

_______________________________________________
foaf-dev mailing list
[email protected]
http://lists.foaf-project.org/mailman/listinfo/foaf-dev