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

Fri Jul 16 12:51:09 CEST 2010

On 16 July 2010 11:49, Reto Bachmann-Gmür <reto at gmuer.ch> wrote:

> On Fri, Jul 16, 2010 at 2:15 AM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
> >
> >
> > On 16 July 2010 00:53, Reto Bachmann-Gmür <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.
>

Just thinking out loud:  would something like 2.2.6 cover retreival of a
public key from a GPG server / mailto URI?

Note: just saw henry's mail suggesting this is out of scope ...

>
>
> 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>
> >> 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
> >> >> 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
> >> > 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100716/45a87ff7/attachment-0001.htm 