[foaf-protocols] WebID pre-alpha specification (uses RDFa)

Kingsley Idehen kidehen at openlinksw.com
Fri Jul 16 14:40:47 CEST 2010


Reto Bachmann-Gmür wrote:
>
> ----- Original message -----
> > Reto the algorithm you have described here is too low level. You are
> > describing the functioning of your code. I think that is something that
> > is more appropriate for an implementation section.
> I'll be able to try and incorporate your suggestions tomorrow. But as 
> for your concern about the level of abstraction I raised the level of 
> abstractions and the flexibility with respect to the previous 
> revisions. If you find a more abstract and better phrasing i would 
> very much welcome it.
> >
> > A few points.
> >
> > 2.2.4 The issue of caching is an optimisation issue. It is part of the
> > web. So an HTTP GET is designed to enable caching. One can remark on
> > this in 2.2.5 but as an implementation issue
> 2.2.4 goes beyond caching as provided by http. Its has more to do with 
> the open world assumption and validity of triples of the web. An agent 
> may assume triples to be valid for a longer time than the http-cache 
> header of the document allow caching. Also it allows application to 
> use other means of etsablishing reasonable believe that the 
> certificate matches the web-id.
>
> Triple store is used in a very broad sense, including anything that 
> can be mapped to triples. Maybe "information source" would be less 
> missleading.
>
> >
> > 2.2.5 I think one could mention GRDDL too there
> >
> > "If a RDF Content could be retrieved this RDF is considered a trusted
> > source."
> >
> > The notion of trusted source is not quite right. What is being fetched
> > is the canonincal meaning of the WebID. Since the meaning then 
> described
> > the WebId referent as the agent that knows the private key of the 
> public
> > key in the certificate, and since the SSL connection showed that the
> > agent at the end of the connection knew the private key, the server can
> > now identify the agent at the end of the connection with the WebID.
>
> This considerations should go in a section for security 
> considerations, proofs and known vulnerabilies (e.g. Reliance on 
> security of the protocol delivering webid profile.
> >
> > 2.2.6 is out of bounds of this minimal specification of the protocol
> >            and so are the following sections
> >
> >          all we are concerned with is one method of determining 
> identity of
> > an agent at the end of an http connection. There are many other ways.
> > Also the logic of what would be required by asking other agents is
> > something that is intersting, but perhaps something for future work.   
> > Once we have a global identity for the agent, we can use things other
> > people have said to reason about him.
> >
> again, triple store is used in a very broad sense, i welcome less 
> missleading terms or desciptions
>

Database or Data Space is much clearer than Triple Store.  We want all 
RDBMS and NoSQL DBMS players to instinctively understand that their 
technologies are relevant infrastructure for this endeavor.

Remember, the WWW started off as an Information Space.

Courtesy of Linked Data, the WWW becoming a Linked Data Space 
(federation of Databases that plug into a Distributed Linked Data Bus).

Profiles reside in HTTP accessible Data Spaces (nee. Web Sites) with 
regards to the WebID protocol.

Disclaimer: I've used the phrases "Data Space" and "Data Spaces" for 
eons. That said, I make no claim of ownership over these terms. Thus, 
please put to use re. how we describe this critical evolution of the Web :-)

Kingsley
>
>
> cheers,
> reto
> >
> > 2.3.4 the SPARQL is wrong.
> >
> >
> >
> >      Henry
> >
> >
> >
> >
> > On 16 Jul 2010, at 10:49, Reto Bachmann-Gmür wrote:
> >
> > > On Fri, Jul 16, 2010 at 2:15 AM, Melvin Carvalho
> > > <melvincarvalho at gmail.com <mailto:melvincarvalho at gmail.com>> wrote:
> > > >
> > > >
> > > > On 16 July 2010 00:53, Reto Bachmann-Gmür <reto at gmuer.ch 
> <mailto:reto at gmuer.ch>> wrote:
> > > > >
> > > > > I've pushed a version which I revised till section 2.2 with some
> > > > > changes in the phrasing of the introduction and keeping the
> > > > > specification independent of the serialization format except for
> > > > > two small sections marked as "disputed sections" that could be
> > > > > omitted without compromising the integrity of the spec.
> > > > >
> > > > > Thanks to Bruno for helping me today and for reviewing section
> > > > > 2.3.1 and 2.3.1 tomorrow.
> > > > >
> > > > > The revised version is here:
> > > > > http://github.com/retobg/webid-spec/blob/master/index.html
> > > >
> > > > Nice!
> > > >
> > > > 2.2.4 and 2.2.6 look quite similar?
> > > Yes, 2.2.4-6 basically says that trusted sources can be used, but 
> that
> > > authentication may not fail as long as no attempt to dereference the
> > > WebId and subsequently verify the claim against the triples therein
> > > has failed.
> > > >
> > > > Does 2.2.4 cover local caching (for example as per 
> mod_authn_webid) ?
> > > yes, a local cache is a trusted service that is usually consulted
> > > before attempting to dereference the WebId, this 2.2.4.
> > >
> > > > Perhaps the use of the term triple store is a bit specific, as the
> > > > cache may be a simplified format?
> > > right, but maybe this should be covered by a generic sentence like
> > >
> > > "Implementations are not required to use the algorithm as written but
> > > MUST produce results equivalent to those produced by the algorithm 
> and
> > > thus be fully interoperable with implementations following this
> > > algorith,"
> > >
> > > or similar somewhere.
> > >
> > >
> > > Reto
> > > >
> > > > >
> > > > > I hope that this text with the two variants it presents helps
> > > > > keeping this discussion factual and productive, and I'm looking
> > > > > forward to feedback on my revisions.
> > > > >
> > > > > Cheers,
> > > > > reto
> > > > >
> > > > > On Thu, Jul 15, 2010 at 8:08 PM, Kingsley Idehen
> > > > > <kidehen at openlinksw.com <mailto:kidehen at openlinksw.com>> wrote:
> > > > > > Nathan wrote:
> > > > > > > Bruno Harbulot wrote:
> > > > > > >
> > > > > > > > On 15/07/10 07:26, Henry Story wrote:
> > > > > > > >
> > > > > > > > > On 15 Jul 2010, at 01:27, Nathan wrote:
> > > > > > > > >
> > > > > > > > > > > +100
> > > > > > > > > > >
> > > > > > > > > > snap - In full agreement with Kingsley and Henry's
> > > > > > > > > > comments
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > That is exactly why I was suggesting that we remain
> > > > > > > > > > > format neutral as much
> > > > > > > > > > > as possible. I think we can suggest that RDF/XML and
> > > > > > > > > > > rdfa as two very likely to be supported formats, as a
> > > > > > > > > > > contingent situation at the time of writing, and
> > > > > > > > > > > one that should probably be supported by any WebID
> > > > > > > > > > > publisher at that time.
> > > > > > > > > > >
> > > > > > > > > > Perhaps it would make sense to sideskirt the formats 
> all
> > > > > > > > > > together, perhaps create a section or accompaniment
> > > > > > > > > > which compares and contrasts the formats showing the
> > > > > > > > > > strong points of each, RDFa for HTML+RDF profiles mixed
> > > > > > > > > > together other lighter formats for bandwidth
> > > > > > > > > > conservation, XML variants for XML toolkit support and
> > > > > > > > > > so forth.
> > > > > > > > > >
> > > > > > > > > I think we are all in agreement essentially.
> > > > > > > > >
> > > > > > > > Definitely not, unfortunately.
> > > > > > > >
> > > > > > > > Flexibility in a specification, but when it's about the 
> core
> > > > > > > > things than
> > > > > > > > make the overall protocol work, it's not a good thing.
> > > > > > > >
> > > > > > > > Not specifying a format is fine if the data is interpreted
> > > > > > > > by humans, machines are not so good for doing what to do if
> > > > > > > > the negotiation fails.
> > > > > > > > The flexibility of the content-negotiation or even the HTML
> > > > > > > > rendering is
> > > > > > > > fine on the web when you're using a browser, because as a
> > > > > > > > human you can
> > > > > > > > choose what to do next.
> > > > > > > > The semantic web could in theory be drawn on paper, sure,
> > > > > > > > but then you get RDF to support its implementation, so that
> > > > > > > > programs can process representations. The next step is
> > > > > > > > indeed the RDF format. I'm afraid that, to implement the
> > > > > > > > semantic web, from theory to practice, you do need those,
> > > > > > > > and you do need adequate support from the libraries.
> > > > > > > >
> > > > > > > > The danger there is by not specifying a format is that you
> > > > > > > > can have two
> > > > > > > > compliant implementations that won't be able to talk to 
> each
> > > > > > > > other. They'll surely blame each other for being wrong,
> > > > > > > > whereas they'll both be
> > > > > > > > right and the spec will have failed to enable them to talk
> > > > > > > > together with
> > > > > > > > certainty (at least if they're compliant and there's no
> > > > > > > > error on the way).
> > > > > > > >
> > > > > > >
> > > > > > > Ack I agree here too, in principal - but..
> > > > > > >
> > > > > > > typically if you need to be able to log somebody in, then you
> > > > > > > need to understand some or all of the profile on the other
> > > > > > > side. This is half (or more of) the point of webID and Linked
> > > > > > > Data etc..
> > > > > > >
> > > > > > > issue is understanding ones Linked Data / Profile (bearing in
> > > > > > > mind it could be for machines, apps, orgs, any agent) so
> > > > > > > what's needed is more a
> > > > > > > generic way to guaranteed Linked Data is accessible - this is
> > > > > > > orthogonal
> > > > > > > (but related) to WebID - and IMHO points to some
> > > > > > > standardization work being done on Linked Data.
> > > > > > >
> > > > > > > However, Linked Data clearly says to publish 'using the
> > > > > > > standards', and clearly states to use Recommendations *and*
> > > > > > > member submissions (stating Turtle, N3 etc as well) - thus,
> > > > > > > perhaps this issue comes down to what a Linked Data client
> > > > > > > must support, or what publishers must support to make
> > > > > > > this whole web of data work.
> > > > > > >
> > > > > > > One for the Linked Data mailing list?
> > > > > > >
> > > > > >
> > > > > > Nathan,
> > > > > >
> > > > > > Very good point.
> > > > > >
> > > > > > The WebID Protocol is an Application of the principles outlined
> > > > > > in the Linked Data meme. Thus, our language should leverage 
> this
> > > > > > vital point when it comes to data representation options.
> > > > > > That's the key here. Even more so as WebID's  next point of
> > > > > > impact is the RWW variant of WWW :-)
> > > > > >
> > > > > > You can't implemented the WebID Protocol without a 
> commitment to
> > > > > > the Linked Data meme.
> > > > > >
> > > > > > TimBL:
> > > > > > I would like to encourage looser language with regards to RDF
> > > > > > and SPARQL re. the latest edition of the Linked Data Design
> > > > > > Issues meme. If we can simply say something like: .... 
> standards
> > > > > > (e.g., RDF, SPARQL etc..). We end up sealing what I continue to
> > > > > > see as an inadvertently introduced FUD vulnerability point
> > > > > > relative to the original FUD proof version of the Linked Data
> > > > > > meme.    It isn't really possible to effectively implement the
> > > > > > essence of the Linked Data meme (in a manner that scales over
> > > > > > the long haul e.g. ACLs and Policy based RWW) without RDF and
> > > > > > SPARQL, I just want people to find that out for themselves :-)
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kingsley
> > > > > > > Best,
> > > > > > >
> > > > > > > Nathan
> > > > > > > _______________________________________________
> > > > > > > foaf-protocols mailing list
> > > > > > > foaf-protocols at lists.foaf-project.org 
> <mailto:foaf-protocols at lists.foaf-project.org>
> > > > > > > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Kingsley Idehen
> > > > > > President & CEO
> > > > > > OpenLink Software
> > > > > > Web: http://www.openlinksw.com
> > > > > > Weblog: http://www.openlinksw.com/blog/~kidehen 
> <http://www.openlinksw.com/blog/%7Ekidehen>
> > > > > > Twitter/Identi.ca: kidehen
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > foaf-protocols mailing list
> > > > > > foaf-protocols at lists.foaf-project.org 
> <mailto:foaf-protocols at lists.foaf-project.org>
> > > > > > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> > > > > >
> > > > > _______________________________________________
> > > > > foaf-protocols mailing list
> > > > > foaf-protocols at lists.foaf-project.org 
> <mailto:foaf-protocols at lists.foaf-project.org>
> > > > > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> > > >
> > > >
> >
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 







More information about the foaf-protocols mailing list