Namespace location #13
4 participants
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-termsis 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)
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.
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.
"+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)?
Original implementations of LDN used/s the
solid-termsnamespace e.g., theinboxproperty which points to the Inbox URL. The spec considers to move this over to theldpnamespace. This issue is intended to have consensus on this proposal.