[foaf-dev] FOAF, property listings, updating shows relations,
subProperty (pun) searches, federate data, friend datameshes,
pwilliams at rapattoni.com
Thu Sep 20 20:18:29 BST 2007
I now have a RDF proxy agent that scapes 2 or more sources of XML (about house forSale listings), and constructs a RDF model. Ive even build a demo rulebase that defined subProperties. The intersection of FOAF/OpenID/SPQRQL seems interesting, as -- or whatever socio-political reason -- folks in almost every locality where houses are bought/sold insist on using local names for the 200 properties of the homes actually for sale. Similarly, the govt land records also express yet more properties, in yet more local names.The rules in my rulebase are thus aiming to allow inferences based on SubProperty (pun) declarations. This would seem to nicely allows a standard query expressed in standard names to be executed against in a wide-area geopgraphy comprising several data sources, each using local names.
I'm thinking of orchestrating things such as a Person's PersonalProfileDocument can have a seeAlso link to the FOAF file of a house listing (yes a FOAF file, tho not necessarily a PersonalProfileDocument ). The home's FOAF would itself be dynamically generated, based on the "screen scaping" of (dynamically generated) XML datasets that can be produced on demand. This notion of a home listing is distinct from the advertisements for homes you would still see all over the place, on the search portals - where snippets of the data is let go into certain various google-style syndication channels - for marketing properties -- much as folks have done for a couple of thousand years!
I'm then thinking about having the Realtor who lists the property be the first friend the house listing FOAF file "knows". When managed by this Realtor denoted as the listing file's "owner", other friends would be added to note who is the broker in charge of that listing Realtor, who are the realtors of the buyer making offers (the brokers of those realtor could be inferred by inspecting the realtors' own FOAF files, as could data about the buyers from any FOAF files they maintain), who is the nominated third party escrow person (and inferred office), who is/are the nominated mortagage person(s) (and inferred bank(s)), who is the formal contact at the govt land office, who is the inspector/fixer/gardener, who is the title agent (and the infered insurance company), who is the planned moving company. And of course, who is/are the seller(s) - if that data is published!
Am I mad and going in the wrong direction with such an application of FOAF?
If its a sane concept, I think Im missing knowhow on how the know's relations are updated. I think I need the equivalent process to how trackbacks work in the cross-blogging world. For all those friends in the network that we just viewed from the perspective of a home listing record, a similar view exists rooted in the record systems of each of the friends. Unlike the predictions made by information system theory, each record maintained at each friend's IT system will actually have its own slave copy of the data that COULD have been auto-inferred from the friend network (e.g. the home's long/lat, address, school destrict). While the values may be inferred the first time to make the slave copy (saving incorrect data entry of the same value in multiple IT systems), the nature of records retention and legal rules insist that slave copies exist in locally maintained records ystems, for long term records rentention obligations in regulated industries. Of course the datamesh is specific to one and only transaction. The next home in closing has a different data mesh of friends/records systems, involved in its particular instance of the process.
The above is of course just exploiting what is commodity-grade knowhow at this point: a federated dataset (from RDF data merging), and a data mesh (from the FOAF friends). Adding openid to the mix would allow any one (licensed) friend to access the other's formal private records management system (operated by the organization in charge) and make inferences for data properties that are not standardized in the FOAF vocabulary. Ideally, the linkup between the FOAF datamesh and openid would allow the know's relation to act as a definition of a whitelist - representing those mutually federating OP who will allow the friends identified as OpenID to perform what OpenID calls Cross Compay Authentication (aka federated webSSO). There is a role of the WOT too, that would take too long to express here.
Just as it took a year to bootstrap webSSO into practice within US organized Realty, it will take at least the same amount of time to get such an idea about web-listings to be primed, get deployable to v1 standard, in put into operation at an early adopter locality. Obviously, the idea wont fly if the technologies undelrying it dont actually work efficiently, or are not mature enough to be deployable in production by the like of folks like me!
Is RDF, FOAF (WOT) and OpenID ready for this kind of critical-infrastructure grade application?
From: foaf-dev-bounces at lists.foaf-project.org on behalf of Dan Brickley
Sent: Thu 9/20/2007 5:05 AM
To: Richard Cyganiak
Subject: Re: [foaf-dev] declare foaf:img as owl:InverseFunctionalProperty ?
Richard Cyganiak wrote:
> I like it. Makes total sense, and one more handy way to smush people.
Yeah, dunno how we missed it before.
> I'd add though: "Warning: Do not use with pictures that prominently show
> more than one person."
Or identical twins? ;)
I'd leave the warnings out of property-specific areas. The property
foaf:img just means what it means, and ideally it would be clear from
the photo to most observers who was the main subject. Very similar to
primaryTopic / isPrimaryTopicOf in that regard. But we can't legislate
Hmm lets chuck in
foaf:img rdfs:subPropertyOf foaf:isPrimaryTopicOf while we're at it?
> I think such a warning should be in the comments of all IFPs. They are
> all a little bit dangerous -- e.g. from the foaf:homepage or foaf:weblog
> comment it's not obvious that the properties MUST NOT be used for shared
> homepages or blogs. An explicit warning would help to avoid accidental
Yep, need some guidance somewhere. In the big messy world, these things
are inevitably going to get a bit heuristicy, and that's OK. Sometimes
people make mistakes, or people share passwords/accounts and the person
who wrote the exporter for that YASN isn't aware. I heard people had
trouble with foaf:weblog on LiveJournal in that regard...
foaf-dev mailing list
foaf-dev at lists.foaf-project.org
More information about the foaf-dev