New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespace location #13

Closed
csarven opened this Issue Jun 28, 2016 · 27 comments

Comments

Projects
None yet
10 participants
@csarven
Member

csarven commented Jun 28, 2016

Original implementations of LDN used/s the solid-terms namespace e.g., the inbox property which points to the Inbox URL. The spec considers to move this over to the ldp namespace. This issue is intended to have consensus on this proposal.

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Jun 30, 2016

Member

Reasons to use the ldp namespace:

  • Closely aligned with the concepts in the LDP vocabulary (without requiring an LDP implementation)
  • Reuse of widely used namespace
  • Interest to the LDN-Next CG.

Reasons against:

  • LDN is a specialisation / particular category of applications and behaviours - solid-terms is more suitable in this case. Plus, additional terms/behaviours (e.g., notification 'read') would be more suitable somewhere other than the ldp ns - (this is not to imply that those additions will have to be in the same ns as the core LDN)
Member

csarven commented Jun 30, 2016

Reasons to use the ldp namespace:

  • Closely aligned with the concepts in the LDP vocabulary (without requiring an LDP implementation)
  • Reuse of widely used namespace
  • Interest to the LDN-Next CG.

Reasons against:

  • LDN is a specialisation / particular category of applications and behaviours - solid-terms is more suitable in this case. Plus, additional terms/behaviours (e.g., notification 'read') would be more suitable somewhere other than the ldp ns - (this is not to imply that those additions will have to be in the same ns as the core LDN)
@melvincarvalho

This comment has been minimized.

Show comment
Hide comment
@melvincarvalho

melvincarvalho Jul 10, 2016

Contributor

If LDP is a webized version of a file system, typically file systems dont have an inbox.

Though inbox is an important app for most people.

So I can see the argument for putting in the LDP namespace and also for not doing that. Perhaps ldp next will have some kind of extension namespaces.

In terms of implementations, this needs to be finalized hopefully quite quickly unless we have implementations support two predicates.

Contributor

melvincarvalho commented Jul 10, 2016

If LDP is a webized version of a file system, typically file systems dont have an inbox.

Though inbox is an important app for most people.

So I can see the argument for putting in the LDP namespace and also for not doing that. Perhaps ldp next will have some kind of extension namespaces.

In terms of implementations, this needs to be finalized hopefully quite quickly unless we have implementations support two predicates.

@nandana

This comment has been minimized.

Show comment
Hide comment
@nandana

nandana Jul 13, 2016

Member

My slight preference would be not to use the LDP namespace. May be just for LDN this might work but I don't think this would most most suitable approach when more extensions start to appear.

+1 for LDP Next to have a extension namespace.

Member

nandana commented Jul 13, 2016

My slight preference would be not to use the LDP namespace. May be just for LDN this might work but I don't think this would most most suitable approach when more extensions start to appear.

+1 for LDP Next to have a extension namespace.

@rhiaro rhiaro referenced this issue Jul 14, 2016

Closed

Aligning ActivitySub and LDN #36

3 of 5 tasks complete
@timbl

This comment has been minimized.

Show comment
Hide comment
@timbl

timbl Jul 25, 2016

"+1 for LDP Next to have a extension namespace." What do you mean by that? A different URI for new terms for people to add things? That to me seems less than ideal. It was a bad idea to make rdf: different from rdfs: I think in retrospect. It was confusing to make dc: and dct: different. I think the community is served better by putting new terms in the old namespace. I thing this term should either go in ldp: or in solid-terms. LDP makes sense if there may all kinds of application areas which use it as a basic way of hanging a handler of a file (like inotify in a file system http://man7.org/linux/man-pages/man7/inotify.7.html)?

timbl commented Jul 25, 2016

"+1 for LDP Next to have a extension namespace." What do you mean by that? A different URI for new terms for people to add things? That to me seems less than ideal. It was a bad idea to make rdf: different from rdfs: I think in retrospect. It was confusing to make dc: and dct: different. I think the community is served better by putting new terms in the old namespace. I thing this term should either go in ldp: or in solid-terms. LDP makes sense if there may all kinds of application areas which use it as a basic way of hanging a handler of a file (like inotify in a file system http://man7.org/linux/man-pages/man7/inotify.7.html)?

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven
Member

csarven commented Aug 3, 2016

Crosslinking to get LDP Next CG's feedback: https://lists.w3.org/Archives/Public/public-ldpnext/2016Aug/0001.html

@azaroth42

This comment has been minimized.

Show comment
Hide comment
@azaroth42

azaroth42 Aug 3, 2016

I'm strongly -1 to using an existing namespace without due process. I can't just create new entries in foaf, dcterms, html, or any other namespace ... and I don't see why ldp's namespace is any different and would formally object on this basis.

azaroth42 commented Aug 3, 2016

I'm strongly -1 to using an existing namespace without due process. I can't just create new entries in foaf, dcterms, html, or any other namespace ... and I don't see why ldp's namespace is any different and would formally object on this basis.

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Aug 3, 2016

@azaroth42 This is due process. W3C groups (and submissions) can write to W3C namespaces, assuming their decisions are made with appropriate public input. The LDN FPWD highlighted the issue ( https://www.w3.org/TR/ldn/#issue-13 ), and @csarven is currently trying to make sure people who might care about this have a chance to weigh in before the relevant Working Group makes its decision.

Does that address your concern?

sandhawke commented Aug 3, 2016

@azaroth42 This is due process. W3C groups (and submissions) can write to W3C namespaces, assuming their decisions are made with appropriate public input. The LDN FPWD highlighted the issue ( https://www.w3.org/TR/ldn/#issue-13 ), and @csarven is currently trying to make sure people who might care about this have a chance to weigh in before the relevant Working Group makes its decision.

Does that address your concern?

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Aug 4, 2016

👍 for using ldp namespace

akuckartz commented Aug 4, 2016

👍 for using ldp namespace

@azaroth42

This comment has been minimized.

Show comment
Hide comment
@azaroth42

azaroth42 Aug 4, 2016

I wish I had realized that! We would have taken over a bunch of namespaces in the Annotation Working Group and fixed them. Notably: https://www.w3.org/TR/Content-in-RDF10/ which we used in the community group's work and then had to change as it's only a WD. And updated PROV so that we could have used it rather than reducing down to dcterms. Bummer.

Last modification wins, regardless of what's in a group's charter, seems inexcusably dangerous to me, but if that's sufficient process, so be it. I look forwards to adding textDirection and processingLanguage retroactively to the ActivityStreams namespace 😉

azaroth42 commented Aug 4, 2016

I wish I had realized that! We would have taken over a bunch of namespaces in the Annotation Working Group and fixed them. Notably: https://www.w3.org/TR/Content-in-RDF10/ which we used in the community group's work and then had to change as it's only a WD. And updated PROV so that we could have used it rather than reducing down to dcterms. Bummer.

Last modification wins, regardless of what's in a group's charter, seems inexcusably dangerous to me, but if that's sufficient process, so be it. I look forwards to adding textDirection and processingLanguage retroactively to the ActivityStreams namespace 😉

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Aug 4, 2016

I'm sorry if you've gotten conflicting messages, @azaroth42. The W3C Staff owes you a consistent policy here. I've raised the issue internally, and hopefully we'll have our stories better aligned in short order.

sandhawke commented Aug 4, 2016

I'm sorry if you've gotten conflicting messages, @azaroth42. The W3C Staff owes you a consistent policy here. I've raised the issue internally, and hopefully we'll have our stories better aligned in short order.

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Aug 9, 2016

Member

If the W3C gig thing doesn't work out, we can consider the following possibilities to have the single property (inbox) that the spec needs:

https://w3id.org/ldn
http://schema.org/

or alternatives:

http://www.w3.org/ns/ldn
http://ietf.org/ldn
http://microformats.org/ns/ldn
urn:LDN
magnet:?xt=urn:btih:071ab45e149b9124137902f3b97831468a94774c&dn=ldn.ttl...
http://doi.org/ldn
http://test@csarven.ca:1234/vocab-dept/v0.5/78/linkedData-NOTIFICATIONS.rdf

Member

csarven commented Aug 9, 2016

If the W3C gig thing doesn't work out, we can consider the following possibilities to have the single property (inbox) that the spec needs:

https://w3id.org/ldn
http://schema.org/

or alternatives:

http://www.w3.org/ns/ldn
http://ietf.org/ldn
http://microformats.org/ns/ldn
urn:LDN
magnet:?xt=urn:btih:071ab45e149b9124137902f3b97831468a94774c&dn=ldn.ttl...
http://doi.org/ldn
http://test@csarven.ca:1234/vocab-dept/v0.5/78/linkedData-NOTIFICATIONS.rdf

@sandhawke

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Aug 9, 2016

Don't forget tag: URIs. :-)

sandhawke commented Aug 9, 2016

Don't forget tag: URIs. :-)

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Sep 13, 2016

Member

Something along the lines of below is what's requested to be added to the LDP ns:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix : <http://www.w3.org/ns/ldp#>.

:inbox
    a rdf:Property;
    rdfs:comment "Links a resource to a container where the notifications can be created and discovered.";
    vs:term_status "stable";
    rdfs:isDefinedBy <https://www.w3.org/TR/ldn/>;
    rdfs:label "inbox";
    dcterms:issued "2016-09-13"^^xsd:date;
    dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>.

(Update: removed domain/range rdfs:Resource)

Member

csarven commented Sep 13, 2016

Something along the lines of below is what's requested to be added to the LDP ns:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix : <http://www.w3.org/ns/ldp#>.

:inbox
    a rdf:Property;
    rdfs:comment "Links a resource to a container where the notifications can be created and discovered.";
    vs:term_status "stable";
    rdfs:isDefinedBy <https://www.w3.org/TR/ldn/>;
    rdfs:label "inbox";
    dcterms:issued "2016-09-13"^^xsd:date;
    dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>.

(Update: removed domain/range rdfs:Resource)

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Sep 13, 2016

@csarven Aren't these two lines redundant?

    rdfs:domain rdfs:Resource;
    rdfs:range rdfs:Resource;

akuckartz commented Sep 13, 2016

@csarven Aren't these two lines redundant?

    rdfs:domain rdfs:Resource;
    rdfs:range rdfs:Resource;
@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Sep 13, 2016

Member

@akuckartz Yes, normally. It follows the LDP vocabulary as close as possible so that if/when it gets added it is uniform with the rest of the definitions. Copy/paste eventually.

Member

csarven commented Sep 13, 2016

@akuckartz Yes, normally. It follows the LDP vocabulary as close as possible so that if/when it gets added it is uniform with the rest of the definitions. Copy/paste eventually.

@timbl

This comment has been minimized.

Show comment
Hide comment
@timbl

timbl Sep 14, 2016

Agree with @akuckartz . Any statements of the form

   rdfs:domain rdfs:Resource;
    rdfs:range rdfs:Resource;

have no information content. They are tautological. Putting them in is bad practice - they should be removed.

timbl commented Sep 14, 2016

Agree with @akuckartz . Any statements of the form

   rdfs:domain rdfs:Resource;
    rdfs:range rdfs:Resource;

have no information content. They are tautological. Putting them in is bad practice - they should be removed.

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Sep 14, 2016

Member

I literally copy/pasted parts from the current curl -H"Accept: text/turtle" http://www.w3.org/ns/ldp, and added new information for ldp:inbox so if any consistency/right/wrong is desired to maintain uniformity after the addition, it is there. I agree that rdfs:Resource is unnecessary. Okay to remove it.

The spec says that any resource can have an Inbox. We implicitly mean rdfs:Resource/owl:Thing, but more importantly a IRI (HTTP URI to be specific).

Member

csarven commented Sep 14, 2016

I literally copy/pasted parts from the current curl -H"Accept: text/turtle" http://www.w3.org/ns/ldp, and added new information for ldp:inbox so if any consistency/right/wrong is desired to maintain uniformity after the addition, it is there. I agree that rdfs:Resource is unnecessary. Okay to remove it.

The spec says that any resource can have an Inbox. We implicitly mean rdfs:Resource/owl:Thing, but more importantly a IRI (HTTP URI to be specific).

@kidehen

This comment has been minimized.

Show comment
Hide comment
@kidehen

kidehen Sep 20, 2016

@csarven, methinks:

{
@Prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@Prefix dcterms: <http://purl.org/dc/terms/>.
@Prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@Prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@Prefix : <http://www.w3.org/ns/ldp#>.

:inbox
a rdf:Property;
rdfs:comment "Links a resource to its Inbox (container) where the notifications can be discovered.";
vs:term_status "stable";
rdfs:isDefinedBy <https://www.w3.org/TR/ldn/> ;
rdfs:label "inbox";
dcterms:issued "2016-09-13"^^xsd:date;
dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>;

Plus

This relations associates People, Organizations, and Documents with an inbox-folder

(and LDP container or WebDAV collection)

schema:domainIncludes schema:CreativeWork, foaf:Document, schema:Person, schema:Organization, foaf:Organization;
schema:rangeIncludes ldp:Container.
}

The definition above will work fine with regards to anything we have, on the Virtuoso and/or Virtuoso+ODS fronts.

If you have an problem with namespaces, just park the new relation definition here:

{
@Prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@Prefix dcterms: <http://purl.org/dc/terms/>.
@Prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@Prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@Prefix : <http://www.w3.org/ns/ldp#>.

<#inbox>
a rdf:Property;
rdfs:comment "Links a resource to its Inbox (container) where the notifications can be discovered.";
vs:term_status "stable";
rdfs:isDefinedBy <#> ;
rdfs:label "inbox";
dcterms:issued "2016-09-13"^^xsd:date;
dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>;

Plus

This relations associates People, Organizations, and Documents with an inbox-folder

(and LDP container or WebDAV collection)

schema:domainIncludes schema:CreativeWork, foaf:Document, schema:Person, schema:Organization, foaf:Organization;
schema:rangeIncludes ldp:Container ;
schema:mainEntityOfPage <https://www.pinterest.com/pin/389561436502292321/> .
}

kidehen commented Sep 20, 2016

@csarven, methinks:

{
@Prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@Prefix dcterms: <http://purl.org/dc/terms/>.
@Prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@Prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@Prefix : <http://www.w3.org/ns/ldp#>.

:inbox
a rdf:Property;
rdfs:comment "Links a resource to its Inbox (container) where the notifications can be discovered.";
vs:term_status "stable";
rdfs:isDefinedBy <https://www.w3.org/TR/ldn/> ;
rdfs:label "inbox";
dcterms:issued "2016-09-13"^^xsd:date;
dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>;

Plus

This relations associates People, Organizations, and Documents with an inbox-folder

(and LDP container or WebDAV collection)

schema:domainIncludes schema:CreativeWork, foaf:Document, schema:Person, schema:Organization, foaf:Organization;
schema:rangeIncludes ldp:Container.
}

The definition above will work fine with regards to anything we have, on the Virtuoso and/or Virtuoso+ODS fronts.

If you have an problem with namespaces, just park the new relation definition here:

{
@Prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@Prefix dcterms: <http://purl.org/dc/terms/>.
@Prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
@Prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@Prefix : <http://www.w3.org/ns/ldp#>.

<#inbox>
a rdf:Property;
rdfs:comment "Links a resource to its Inbox (container) where the notifications can be discovered.";
vs:term_status "stable";
rdfs:isDefinedBy <#> ;
rdfs:label "inbox";
dcterms:issued "2016-09-13"^^xsd:date;
dcterms:creator <http://csarven.ca/#i>, <https://rhiaro.co.uk/#me>;

Plus

This relations associates People, Organizations, and Documents with an inbox-folder

(and LDP container or WebDAV collection)

schema:domainIncludes schema:CreativeWork, foaf:Document, schema:Person, schema:Organization, foaf:Organization;
schema:rangeIncludes ldp:Container ;
schema:mainEntityOfPage <https://www.pinterest.com/pin/389561436502292321/> .
}

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Sep 23, 2016

Member

We discussed this at the breakout session at TPAC, which had lots of LDP people in the room, and there were no objections to the specific proposal to add inbox to the LDP namespace.

W3C policy on this is still being decided though.

Question: If there are no objections from community and no W3C legal issues, can we proceed with this without a longer term W3C process?

Member

rhiaro commented Sep 23, 2016

We discussed this at the breakout session at TPAC, which had lots of LDP people in the room, and there were no objections to the specific proposal to add inbox to the LDP namespace.

W3C policy on this is still being decided though.

Question: If there are no objections from community and no W3C legal issues, can we proceed with this without a longer term W3C process?

@azaroth42

This comment has been minimized.

Show comment
Hide comment
@azaroth42

azaroth42 Sep 23, 2016

I'll moderate my -1 to -0. I think it sets a bad precedent for groups to be changing each others' specifications, but as there's currently no process, I'll keep my discussion to that thread. I have no objections to this specific addition, other than that no one will know what inbox means as it's not part of the LDP TR.

azaroth42 commented Sep 23, 2016

I'll moderate my -1 to -0. I think it sets a bad precedent for groups to be changing each others' specifications, but as there's currently no process, I'll keep my discussion to that thread. I have no objections to this specific addition, other than that no one will know what inbox means as it's not part of the LDP TR.

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Sep 23, 2016

Member

I agree process is preferable. But I don't want to get stuck.

no one will know what inbox means as it's not part of the LDP TR

In the namespace we will include a link to the spec that does define it, so people won't know what it means only if they fail to read that. If they're looking at the ns they have to try really hard not to see it.

Member

rhiaro commented Sep 23, 2016

I agree process is preferable. But I don't want to get stuck.

no one will know what inbox means as it's not part of the LDP TR

In the namespace we will include a link to the spec that does define it, so people won't know what it means only if they fail to read that. If they're looking at the ns they have to try really hard not to see it.

@azaroth42

This comment has been minimized.

Show comment
Hide comment
@azaroth42

azaroth42 Sep 23, 2016

Sorry, missed the rdfs:isDefinedBy link. Still -0, but that should cover it.

azaroth42 commented Sep 23, 2016

Sorry, missed the rdfs:isDefinedBy link. Still -0, but that should cover it.

@kidehen

This comment has been minimized.

Show comment
Hide comment
@kidehen

kidehen Sep 23, 2016

@csarven note my update to #13 (comment) which includes:

Methinks, actually having a resolvable description of a relation that's machine- and human-comprehensible is more important than its namespace i.e., W3C namespace grounding doesn't guarantee relation comprehension or adoption which are the most important factors here :)

kidehen commented Sep 23, 2016

@csarven note my update to #13 (comment) which includes:

Methinks, actually having a resolvable description of a relation that's machine- and human-comprehensible is more important than its namespace i.e., W3C namespace grounding doesn't guarantee relation comprehension or adoption which are the most important factors here :)

@nandana

This comment has been minimized.

Show comment
Hide comment
@nandana

nandana Sep 23, 2016

Member

After the TPAC discussions, I am +1 for using the LDP namespace. With rdfs:isDefinedBy, dcterms:issued, dcterms:creator properties, I guess it is clear that the term was added later and where it was defined.

The only other concern I had was that a developer looking at the namespace document might come to the conclusion that a generic LDP client/server should understand the semantics of the "inbox" property (which is not the case, right?). However, currently the namespace doc seems to have enough information to tell that it is coming from a separate spec.

Member

nandana commented Sep 23, 2016

After the TPAC discussions, I am +1 for using the LDP namespace. With rdfs:isDefinedBy, dcterms:issued, dcterms:creator properties, I guess it is clear that the term was added later and where it was defined.

The only other concern I had was that a developer looking at the namespace document might come to the conclusion that a generic LDP client/server should understand the semantics of the "inbox" property (which is not the case, right?). However, currently the namespace doc seems to have enough information to tell that it is coming from a separate spec.

@csarven

This comment has been minimized.

Show comment
Hide comment
@csarven

csarven Sep 26, 2016

Member

Proposal to add to the JSON-LD context ( http://www.w3.org/ns/ldp.jsonld ):

"inbox": {"@id": "ldp:inbox", "@type":"@id"}
Member

csarven commented Sep 26, 2016

Proposal to add to the JSON-LD context ( http://www.w3.org/ns/ldp.jsonld ):

"inbox": {"@id": "ldp:inbox", "@type":"@id"}
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Sep 28, 2016

+1 for adding it to LDP. If you hit obstacles, give me a shout and we could look at whether schema.org might work instead. But LDP seems a natural home for it...

danbri commented Sep 28, 2016

+1 for adding it to LDP. If you hit obstacles, give me a shout and we could look at whether schema.org might work instead. But LDP seems a natural home for it...

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 6, 2016

Member

Following discussion on this thread, mailing list outreach, in-person at TPAC, and internal at W3C, it seems like adding inbox to the LDP namespace is probably fine, so I've done so, with the disclaimer that if LDN doesn't make it to rec in the end it'll be removed.

Member

rhiaro commented Oct 6, 2016

Following discussion on this thread, mailing list outreach, in-person at TPAC, and internal at W3C, it seems like adding inbox to the LDP namespace is probably fine, so I've done so, with the disclaimer that if LDN doesn't make it to rec in the end it'll be removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment