[rdfweb-dev] NEEDED: SIMPLE FOAF->Javabeans conversion
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
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