Re: [webid spec] overview section

+1 for placing these remarks in non-norminative sections, and keeping it
short.

Steph.

On Tue, Nov 20, 2012 at 3:31 PM, Henry Story <henry.story@bblfish.net>wrote:

>
> On 20 Nov 2012, at 21:23, Andrei SAMBRA <andrei.sambra@gmail.com> wrote:
>
> On Tue, Nov 20, 2012 at 2:58 PM, Henry Story <henry.story@bblfish.net>wrote:
>
>>
>> On 20 Nov 2012, at 20:50, Andrei SAMBRA <andrei.sambra@gmail.com> wrote:
>>
>> On Tue, Nov 20, 2012 at 2:36 PM, Henry Story <henry.story@bblfish.net>wrote:
>>
>>> The graphic showing the picture of TimBL should I think belong to an
>>> overview section ( replacing the current section 3 ) that would explain:
>>>
>>
>> I agree. I'll get right on it.
>>
>>
>>>  1. The full uri denotes the agent TimBl
>>>  2. that the uri minus the hash denotes the document
>>>  3. that the document SHOULD describe the agent in a uniquely
>>> identifiable way, so that the
>>>     agent can be distinguished from every other agent via this
>>> definition.
>>>     ( so here one can specify that this is very general: a public key, a
>>> link to the profile document,
>>>       a link to an e-mail address, any or more will do )
>>>     ( the reason is that otherwise one would need a backchannel to know
>>> what the WebID refers to )
>>>
>>> for 1 and 2 refer to the URI rfc spec on fragment identifiers.
>>>
>>> ---
>>>
>>>   I think it may be useful also to explain how these WebIDs can then be
>>> used to
>>> create social networks - across servers. ( I can send a graphic of
>>> interlinked WebIDs for
>>> that ).
>>>
>>
>> Isn't this out of scope for the spec? It's up to each of us to decide how
>> we want to use WebIDs.
>>
>>
>> Once you publish a WebID you cannot stop people from linking to it.  The
>> point of WebIDs is
>> to allow the build a linked data space: a social web.  This is not
>> something that is a side issue,
>> it is pretty core. We don't need to go into great details about this. We
>> don't have to explain which
>> relations must or should be used, but pointing out that one can link is
>> important.
>>
>
> I agree, and I think that happens by default in the world of linked data,
> where URIs are dereferanceable instead of being an arbitrary graph name
> (like it happens for static RDF). By definition, the WebID URI is
> dereferenceable, so it's like saying that you have HTTP links links. Maybe
> I'm not expressing myself clearly...
>
>
> I am not sure if you are disagreeing with me anymore.
>
> It may be the default, but explaining it is important. Just like you also
> show how one can write a
> profile document, or how URIs work. All of this is evident in some way.
>
> From experience I know that I have spent a lot of time explaining to
> people that foaf profiles did
> not have to be public. This not having been explained is part of what lead
> the OpenID group to
> do their complicated attributed exchange protocol, where the user could
> choose which attributes
> which user would see.
>
> The easy linkability of WebIDs is what makes them so useful.
>
>
>
>>
>> Whether the claims these people make are true or not is something else. I
>> think we should say
>> something on this topic too. If someone links to your webId saying they
>> foaf:know you then an
>> agent that reads that should only belieave that insofar as they believe
>> the original document. If
>> there is a link back, then that counts as confirmation.
>>
>
> Agreed, but at this point, the agent has passed the WebID point, and
> reached the point where it uses returned data for a specific purpose.
>
>
> I am just saying that we can hint at these things lightly in non normative
> contexts.
>
>
>
>>
>>>
>>> ---
>>>
>>>   It may also be useful to show how one can have a WebID profile link to
>>> protected
>>> profile document. ( an adapted version of the WebID-TLS spec graphics ),
>>> as otherwise
>>> people will cry out that this creates anonymity problems.
>>>
>>>
>> Mentioning protected documents (ACL) at this point will open the door to
>> a lot of questions. I guess it's the same reason LDP doesn't mention it
>> either, and they really need it.
>>
>>
>> We don't have to say how the documents are authenticate an agent that
>> requests it, just that
>> there can be protected documents. Otherwise you will just get people
>> thinking that all information
>> has to be public and you will get the privacy folsk asking questions
>> every day. So if you want
>> to be here for the forseable future answering the questions of every
>> privacy person who comes along...
>>
>
> Right, I see. So we could mention that one may split the profile document
> into multiple documents, and then add seeAlso relations to them. Would that
> be acceptable in a non-normative context?
>
>
> yes, in non-normative contexts. What the relation should be would be
> interesting to know but need not be settled. a sub relation of rdf:seeAlso
> I suppose.
>
>
>
> Andrei
>
>>
>> Andrei
>>
>>
>>>
>>>
>>> Henry
>>>
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>  Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>


-- 
Steph.