[foaf-protocols] FOAF+ssl, db engine....
home_pw at msn.com
Mon Jan 18 17:23:37 CET 2010
"the co-chairs of the WG, I'd be very happy to hear more from you regarding
I was very badly taught data management at university - and so avoided it
for 20 years. So forgive my obvious ignorance and lack of decent
organization in what follow. Only recently (with rdf and linq) have I got
interested - as the world of data and internet protocols are merging. (I was
well taught telco communications theory and practice!) But, I have do real
data web-centric problems to solve today, hopefully exploiting the linked
data doctrine. Reading this MAY provide a view of requirements, as seen by a
If it helps, we often use relational stores for object-centric data models
in US realty (and have done since microsoft.realty helped the industry
invent the so-called "RETS" protocol/datamodel - a decade a more ago).
Commonly, the rets query engine/server (think sparql server) is implemented
as a realtime server-side mapper onto a classical, normalized OLTP
relational store (organized to support a session-driven server-side web
app). The mapper maintains and exports its object<->view metadata, which can
be further projected by classical re-mappers like ODBC/JDBC on the client.
If one is familiar with data services in the windows world, additional
client-side metadata mapping can then occur based on the ODBC (OLE/COM)
types to create xsd file (that in turn are the basis for an class that
automatically exports the CRUD operations using RESTful Urls (upon which one
builds ATOM serializers into the communication stack, etc)). Or, one uses
C#'s linq2dataset driver to create a functional query interface (which can
be remoted to clients using SOAP proxies, obviously).
It's into THAT last world (talk functionally to the dataset) that we are
focusing our web-centric security analysis - wanting to leverage security
token passing for (i) the remoting of the communication objects/interfaces
(obviously) AND (ii) link those tokens to the access to the served-side data
access methods (as they mapp, remap, and further map the relational
tables/views at the root of the data access path) using one or more
intermediating entity models.
Now implementation wise, Im at the point where I can dynamically create
readonly foaf cards for the member objects already supported in the RETS
data model (which has just done n layers of metadata mapping and type
conversion, remember from a relational store). And, I can create a triple
memory store for all such objects (i.e. I periodically locally crawl my
object space and cache a triple store). Onto that, the foaf+ssl demo exports
the sparql protocol interface (from the .NET SemWEb toolkit). It's a lab
"model" with 10 recordsets - but it works! Obviously, the underlying rets
server is professionally engineered, and pumps out billions of mapped
recordsets a day to thousands of sinks (who just stuff it back into SQL, in
But the question I have is: why bother! Adding sparql and rdf metadata
mapping into an already overly bloated metadata mapping world is not
helping. The RDF model WITH SECURITY TOKENS needs to be something more than
yet another mapper. And, it has to be more than an engine allowing clients
to use lazy evaluation of joins, when deferencing property relations to
their values. When mappers reflect on the metadata, they somehow need to be
intelligent - inferring the wider authorization model as they walk the parse
tree of the ontologies ... to then generate the implementation of the
What I like about the foaf and linked data movement is... that its NOT about
all the above. It seems to be about something that is quite aligned with
realty (again). IN realty, 1,000,000 independent contractors (called
realtors) each manage their fraction of the source data of the collective.
Each is thus a data source (often with a vanity website, helping market that
one woman's own business "being an agent"). I have to envision a world in
which there are thus 1,000,0000 sparql servers out there, which are crawled
using easy joins "as necessary".
Since Im a ex-directory security specialist, Im trying very hard NOT to
think simply as one would when using X.500 directory engineering techniques!
Rather,... think semweb, Peter!
As the realtors are organized by various overlapping markets that rapidly
shift, security token passing is perfect for the security model - as
specifically federated token passing models allow for the injection of n
trust fabrics, reciprocity agreements for authorization logics, and metadata
mapping sets for projecting dataset federations. In this way, the weird and
wonderful and ever changing organizational constructs of the realty business
space CAN be addressed, using generic tool chains.
I Hope that this characterization of how a NON-data person thinks about
web-data helps the standards community. Its not very academic, and not very
data professional. But that's the point: it's a view of what its like in the
trenches, working with crappy data consistency, a 1000 buggy schemas...built
on commodity data management tools in a windows server farm.
Now I have not mentioned rdfa in the above. I'm also interested if, through
a web revolution/revolt, all the above is discarded - and I can simply take
my existing web app's HTML, throw some rdfa tags in there... and be done
with it. The existing HTML page in the web app becomes the data source.
Thus, the existing My web app becomes the data source. Obviously, existing
websso (saml, openid, foaf+ssl) already gives me security tokens (and
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Michael
Sent: Monday, January 18, 2010 12:32 AM
To: Story Henry; Michael Andronov
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] FOAF+ssl, db engine....
Concerning Linked Data aspects, incl. access and trust, see . As one of
the co-chairs of the WG, I'd be very happy to hear more from you regarding
these topics (best via mail to public-rdb2rdf-comments at w3.org or private to
me, in case you prefer anonymous comments ;)
More information about the foaf-protocols