[rdfweb-dev] NEEDED: SIMPLE FOAF->Javabeans conversion

Danny Ayers danny666 at virgilio.it
Thu May 6 13:15:03 UTC 2004

Julian Bond wrote:

> Ian Davis <iand at internetalchemy.org> wrote:
>> Thursday, May 6, 2004, 7:35:39 AM, you wrote:
>> VL> Danny wrote:
>>>> Add single fields (this.mbox, this.homepage) for the IFPs ...
>> VL> Do IFPs have a cardinality of 1? I have two foaf:mbox_sha1sum in 
>> my FOAF
>> VL> file. Is this wrong?
>> No. I think Danny meant functional properties (things that resources can
>> only have one of, e.g. date of birth)
> Actually I don't think Danny meant that at all. I think he meant 
> properties where the constrained set of data means that there is 
> probably only one entry. But then Danny should set us right.
Danny will defer to his peers, and try to refrain from posting when 
half-asleep ;-)

Yep, I was thinking back to front...

> This is at the core of what makes FOAF so hard to work with in real 
> world situations. Let's say that we're building a system purely to 
> share account information to and from Ecademy and Tribe. Like most of 
> these systems we collect a limited amount of data about the person and 
> typically only have a single field for email address, homepage, mobile 
> phone number. So the FOAF is only ever going to have one entry for 
> each of these. So we can code assuming only one entry. Then we make it 
> more general and the first FOAF we try and use doesn't fit this model 
> at all, at all. It's got multiple entries for lots of the fields. It 
> uses logo instead of img or depiction. It uses the relationship schema 
> instead of knows.
> Which is why FOAFnet is trying to come up with a common subset of 
> elements with a best practice schema for use in account sharing. Given 
> that, it should be possible to create a javabean that reflects the 
> subset and schema. Until one or more of us extend the schema and start 
> using other FOAF and RDF practices in the same files.

There was a constraint given on the original query, that was to use 
Javabeans (if I understood correctly, so that an existing object store 
could be used). I couldn't find any existing toolkit that allowed this 
in a simple fashion. My late-night suggestion (hastily reworked to 
include multiple values for all fields) was a quick-and-dirty approach 
that might make it possible to deal with say 80% of FOAF files (those 
from the controlled sources) without using a true RDF store. I'm now 
regretting making that suggestion somewhat... This approach would 
certainly fit with a common subset schema, and such a schema would make 
it a lot easier to e.g. build a store based on a regular RDBMS.  But 
making a rigid schema would be throwing quite a lot of baby out with the 
bathwater. So rather than defining a subset of elements to move that % 
upwards, it would be better to move the implementation closer to the 
model, in other words use a true RDF store. This may mean more work up 
front if it had to be compatible with an existing object store, but 
would leave future options wide open.
(The up-front work could be reduced considerably by using an existing 
parser (such as ARP)).



More information about the foaf-dev mailing list