[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)

Stéphane Corlosquet scorlosquet at gmail.com
Mon Aug 2 18:45:23 CEST 2010

On Mon, Aug 2, 2010 at 12:30 PM, Henry Story <henry.story at gmail.com> wrote:

> Where is the latest version of the spec so that I can edit that? I'd like
> to just put some text together for a proposal.

The main branch is http://github.com/msporny/webid-spec but I've been making
changes at http://github.com/scor/webid-spec. You can see at anytime the
status of the various forks at
http://github.com/msporny/webid-spec/network(which Manu merges back
into his own every few days or so after review).


> On 2 Aug 2010, at 18:23, Nathan wrote:
> >>>>
> >>> It's quite a different thing though.
> >> No it isn't.
> >> Henry is making the same point that I am making.
> >> We can get there by separating Semantics from Data Representation.
> >> We MUST have Structured Profile Documents that have HTML
> representations.
> >> The REST is simply about implementor specific details.
> >> Remember, the best way to really appreciate HTML+RDFa is by attempting
> to reinvent it en route to producing a Structured Profile Document that is
> Human and Machine readable.
> >
> > yes, we could easily accomplish everything needed with *only* RDFa.
> >
> > I for one would be happy to go balls out and specify 'MUST use RDFa'
> only, would anybody here who has a WebID or a foaf profile have any good
> reason not to do this?
> >
> > I could debate every other serialization till the end of time, RDFa I
> can't - so why add any others in to the mix.
> Because it is often difficult to do RDFa right. On small sites it is very
> easy for people to edit an RDFa template without understanding the
> consequences to the RDF of their actions. Generating RDF/XML automatically
> is a lot easier to do.
> More and more Content Management Systems, have an object view of the data
> stored. Even a real simple one such as XWIki has that. If one knows what
> types of objects get displayed on a html page, it is very easy to
> automatically use that information to generate RDF/XML.
> > Caveat, if any others are added in, then all must be for (other than N3)
> they are all equal - RDFa rises above because it's Human Readable, N3 rises
> above for obvious reasons, but those N3 reasons aren't needed for this
> protocol.
> In the end the consumer - aka Relying Party - should accept as many formats
> as he can get away with. And the publisher should publish one well known
> format. Clearly  the established RDF formats have been researched in most
> depth, and it should support those. If new formats come along and manage in
> one way or another to push themselves on the scene, then RPs will have a big
> advantage in supporting those too.
> Henry
> >
> > Best,
> >
> > Nathan
> _______________________________________________
> 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/20100802/86ac7585/attachment.htm 

More information about the foaf-protocols mailing list