Re: WebID definition proposal with hash urls

On Thu, Nov 15, 2012 at 6:32 PM, Henry Story <henry.story@bblfish.net>wrote:

>
> On 16 Nov 2012, at 00:27, Henry Story <henry.story@bblfish.net> wrote:
>
> > The way to change the spec is to propose textual spec changes. Could
> those who wish
> > to support the #url simpliciations please put forward some clear text
> that the editors
> > can add to the spec, so that people can then vote on it.
> >
> > I think this does simplify the spec, and it does not break anything,
> since we had already
> > agreed to Turtle and RDFa being a MUST.
> >
> > Currently we have is:
> >
> > WebID:
> >
> > <blockquote src="
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html " >
> > A URI that refers to an Agent - Person, Robot, Group or other thing that
> can have Intentions. The WebID should be a URI which when dereferenced
> returns a representation whose description uniquely identifies the Agent
> who is the controller of a public key. In our example the WebID refers to
> Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is
> defined in the document refered to by the WebID URL without the #tag .
> > </blockquote>
> >
> > WebID Profile
> >
> > <blockquote src="
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html" >
> > A structured document asserting the relationship between the Subject
> (identified by his WebID) and his Public Keys using relationships as
> defined by the Resource Description Framework [RDF-CONCEPTS] and published
> at the URL location of the Subject's WebID. Dereferencing the WebID should
> return the Profile Page in one of a number of formats. The Server must
> publish the document in at least the RDFa [RDFA-CORE] serialization format
> or in Turtle [TURTLE-TR]. The document may be published in a number of
> other RDF serialization formats, such as RDF/XML [RDF-PRIMER], or N3 [N3].
> Any other serializations that intend to be used by the WebID Protocol must
> be transformable automatically and in a standard manner to an RDF Graph,
> using technologies such as GRDDL [GRDDL-PRIMER].
> > </blockquote>
> >
> >
> > Proposal 1: with hash urls
> > ===========================
> >
> >
> > a) A WebID is a URI [1] whose scheme is either "http" or "https" and
> that contains a fragment identifier.
> > The WebID denotes an Agent ( Person, Organisation, Group, Software,
> ...). The URI without the hash denotes the WebID Profile.
> >
>

+1 to a)


>  > b) A WebID Profile is a web resource that MUST by default return a
> TURTLE document, but that
> > can return other RDF serialisation formats if requested through content
> negotiation. The RDF
> > graph expressed by this turtle document MUST contain a number of
> relations containing the WebID
> > that uniquely identify the referent of the WebID.
>

My version:

b) A WebID Profile is a web resource that MUST return a Turtle document,
but MAY return a document using different serialization formats. The
returned RDF data MUST contain a set of relations that uniquely identify
the referent of the WebID.


> My problem with this definition is that we now need to define a special
> type of WebID Profile for WebID over TLS, since in the WebID over TLS spec
> we need the profile document to contain a public key.


It doesn't have to be a special type of WebID Profile. We can see from
http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability that
it becomes easier for consumers of your WebID Profile to decide on their
own which authentication protocol they like best, as long as you provide
them with different choices (WebID principal, OpenID principal, etc.).


> >
> > Proposal 2:
> > ==========
> >
> > like proposal 1 but
> >
> > b) the WebID Profile MUST either return RDFa or Turtle
>

"Either" means having to implement/support both serialization formats. As
far as I can see (from most specs and libraries), turtle is the preferred
format.


> >
> >
> > [1] http://tools.ietf.org/html/rfc3986
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>
> Social Web Architect
> http://bblfish.net/
>
>

Received on Friday, 16 November 2012 00:03:03 UTC