ISSUE-57: How can a client determine that it is in communication with an LDP server?

LDP Service ID

How can a client determine that it is in communication with an LDP server?

State:
CLOSED
Product:
Linked Data Platform Spec
Raised by:
David Wood
Opened on:
2013-03-15
Description:
I contend that several possible communications between client and LDP server would benefit from a client knowing that it is speaking with an LDP service. If that statement turns out to be true, LDP servers may wish to advertise their LDP compliance (e.g. via an HTTP header).

A client will need to discover (either via a discovery mechanism or a priori) a URL to POST, PUT or PATCH an LDPR. It will also need to know the formats it can POST, PUT or PATCH and any server version restrictions (e.g. whether a particular server supports modifications to the PATCH format). Those particular concerns may be addressed by the answers to ISSUE-17 and ISSUE-56.

However, a client may POST, PUT or PATCH a binary object to an LDPC and MAY (in accordance with ISSUE-15) get back both Location: and Link: headers in a 201 Created response. The client will not know how to deal with the possible Link: header, nor its relationship to the binary object's URI, unless it knows that the server is an LDP server.

It seems to me that these concerns would be best addressed by the server advertising via an HTTP header that it supports a particular version of the LDP spec.

Related issues include container affordances (ISSUE-21), the LDP-specific PATCH format (ISSUE-17) and discovering LDPR PUT URLs (ISSUE-56).

NB: The answer to ISSUE-32 may or may not provide an answer to this issue as well. If so, this issue may be closed concurrently.
Related Actions Items:
Related emails:
  1. LDP Rec (from eric@w3.org on 2015-02-20)
  2. Re: Discovery/Affordances (Issue-32/Issue-57) (from Erik.Wilde@emc.com on 2013-06-14)
  3. Re: Discovery/Affordances (Issue-32/Issue-57) (from tthibodeau@openlinksw.com on 2013-06-14)
  4. Re: LDP-Server - Issue-57 (from roger.menday@uk.fujitsu.com on 2013-06-14)
  5. Re: LDP-Server - Issue-57 (from henry.story@bblfish.net on 2013-06-14)
  6. Re: LDP-Server - Issue-57 (from Erik.Wilde@emc.com on 2013-06-14)
  7. Re: LDP-Server - Issue-57 (from lehors@us.ibm.com on 2013-06-14)
  8. Re: LDP-Server - Issue-57 (from henry.story@bblfish.net on 2013-06-14)
  9. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-14)
  10. Re: LDP-Server - Issue-57 (from lehors@us.ibm.com on 2013-06-14)
  11. Re: Discovery/Affordances (Issue-32/Issue-57) (from kidehen@openlinksw.com on 2013-06-13)
  12. Re: Discovery/Affordances (Issue-32/Issue-57) (from Erik.Wilde@emc.com on 2013-06-13)
  13. Re: LDP-Server - Issue-57 (from henry.story@bblfish.net on 2013-06-13)
  14. Re: Discovery/Affordances (Issue-32/Issue-57) (from pierre-antoine.champin@liris.cnrs.fr on 2013-06-13)
  15. Re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-13)
  16. Re: LDP-Server - Issue-57 (from lehors@us.ibm.com on 2013-06-13)
  17. Re: LDP-Server - Issue-57 (from henry.story@bblfish.net on 2013-06-13)
  18. Re: LDP-Server - Issue-57 (from henry.story@bblfish.net on 2013-06-13)
  19. Re: Discovery/Affordances (Issue-32/Issue-57) (from bertails@w3.org on 2013-06-13)
  20. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-13)
  21. Re: LDP-Server - Issue-58 (from lehors@us.ibm.com on 2013-06-13)
  22. Re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-13)
  23. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-13)
  24. Re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-12)
  25. Re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-12)
  26. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-11)
  27. Re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-11)
  28. re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-11)
  29. Re: Discovery/Affordances (Issue-32/Issue-57) (from kidehen@openlinksw.com on 2013-06-11)
  30. re: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-11)
  31. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-11)
  32. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from Erik.Wilde@emc.com on 2013-06-11)
  33. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from kidehen@openlinksw.com on 2013-06-11)
  34. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-11)
  35. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-11)
  36. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-11)
  37. Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-11)
  38. proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57) (from henry.story@bblfish.net on 2013-06-11)
  39. Re: Discovery/Affordances (Issue-32/Issue-57) (from Erik.Wilde@emc.com on 2013-06-10)
  40. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-10)
  41. Re: Discovery/Affordances (Issue-32/Issue-57) (from kidehen@openlinksw.com on 2013-06-10)
  42. Re: Discovery/Affordances (Issue-32/Issue-57) (from kidehen@openlinksw.com on 2013-06-10)
  43. Re: Discovery/Affordances (Issue-32/Issue-57) (from Erik.Wilde@emc.com on 2013-06-10)
  44. Re: Discovery/Affordances (Issue-32/Issue-57) (from lehors@us.ibm.com on 2013-06-10)
  45. Re: Discovery/Affordances (from henry.story@bblfish.net on 2013-06-10)
  46. Re: Discovery/Affordances (from lehors@us.ibm.com on 2013-06-10)
  47. ISSUE-56/ISSUE-57 (from Erik.Wilde@emc.com on 2013-05-30)
  48. Re: Define a minimal restriction on LDPR representations (from rgarcia@fi.upm.es on 2013-05-17)
  49. Re: Define a minimal restriction on LDPR representations (from ashok.malhotra@oracle.com on 2013-05-16)
  50. Re: ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-16)
  51. Re: ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core] (from kidehen@openlinksw.com on 2013-03-15)
  52. Re: ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-15)
  53. ldp-ISSUE-57 (LDP Service ID): How can a client determine that it is in communication with an LDP service? [Linked Data Platform core] (from sysbot+tracker@w3.org on 2013-03-15)

Related notes:

Closed, adding that LDP servers MUST advertise LDP with a link header: Link: <http://www.w3.org/ns/ldp/Resource>; rel=type (and noting that we consider rel=type to be shorthand for the rdf:type property). And we/others can subclass ldp:Resource as needed later.
See: http://www.w3.org/2013/meeting/ldp/2013-06-18#resolution_1

Arnaud Le Hors, 18 Jun 2013, 23:44:32

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 57.html,v 1.1 2015/08/17 04:43:10 denis Exp $