mike amundsen wrote:
<snip from Kingsley>
(the resource URL is discoverable via Link: response headers):
</snip>
<snip from Nathan>
try:
https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt,acl
</snip>
Hopefully, the irony is not lost here.
Kingsley's message listed a URI of a resource; the LInk header of
which pointed to the URI of the ACL resource.
IOW, I was given rights to the ACL resource, but not the resource
controlled by that ACL resource.
Thus, "Discovering the ACL resource via the Link Header" *was not possible*.
So I must ask, Nathan, how did you know the URI of the ACL resource?
What have I missed?
Yes, the original plan was for Nathan to pass to one of the FOAF+SSL
crew and so on. That's said, I should have started with the FOAF+SSL
crew all on a level footing, less confusing that way.
ACL updated now, so all FOAF+SSL crew members are now on par with Nathan
i.e., you can de-ref the resource URL which exposes its associated ACL
resource via response headers. You can then add or remove other members
the ACL (note: "append" mode isn't there yet so you can "add" or
"remove" members).
Kingsley
mca
http://amundsen.com/blog/
http://mamund.com/foaf.rdf#me
On Sat, Jun 19, 2010 at 11:37, Nathan <nat...@webr3.org> wrote:
try:
https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt,acl
note the ,acl
Nathan :)
mike amundsen wrote:
Kingsley:
thanks for continuing to post examples/tests like this for us to work
through.
When I attempt to deref the URI:
https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt
I am asked for my cert (supplied) and I am presetned with the HTTP
Auth challenge.
IOW, I'm not able to load the file and cannot continue.
mca
http://amundsen.com/blog/
http://mamund.com/foaf.rdf#me
On Sat, Jun 19, 2010 at 09:58, Kingsley Idehen <kide...@openlinksw.com>
wrote:
All,
FOAF+SSL protected resource URL:
<https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt>
.
Step 1.
If you are new to these test (I suspect most on the LOD list), you will
need to have a WebID in the ACL associated with the URL above. Thus,
failure to successfully de-reference the URL is success (i.e. you see a
WebDAV challenge due to your FOAF+SSL authentication challenge failure).
Step 2.
I've given the added the following FOAF+SSL crew members "write"
privileges on the ACL resource for
<https://ods-qa.openlinksw.com/home/dav/Public/fao_to_sumo_mappings.txt>
(the resource URL is discoverable via Link: response headers):
1. Nathan - <http://webr3.org/nathan#me>
2. Henry - <http://bblfish.net/people/henry/card#me>
3. Melvin - <http://foaf.me/melvincarvalho#me>
4. Mike - <http://mamund.com/foaf.rdf#me>
5. Michael Hausenblas - <http://sw-app.org/mic.xhtml#i> .
Step 3.
Each of the individuals above are in a position to extend the ACL
membership, courtesy of privileges assigned to their WebIDs, via a
WebDAV aware client (which includes all major operating systems these
days). Thus, via WebDAV you can simply edit the N3 representation of the
ACL resource.
Once we get this process nailed, we will then up the ante with ping
based notices such that ACL membership changes are propagated via ping
based notifications to affected individuals (by sniffing their "ping
service endpoints" which should become part of the structured FOAF based
profiles associated with their WebIDs).
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
_______________________________________________
foaf-protocols mailing list
foaf-protoc...@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
