Hi All,
I can't edit the wiki, and I can't attend the telecon due to it being
the only time of the day I can't manage (1500-1600UTC). so here's my
feedback, broken down in to several sections.
General Architectural Principals:
============================================
1) "Being part of a Modular Design
It is not only necessary to make sure your own system is designed to be
made of modular parts. It is also necessary to realize that your own
system, no matter how big and wonderful it seems now, should always be
designed to be a part of another larger system."
~ http://www.w3.org/DesignIssues/Principles.html
In the context of WebID 1.0, we must acknowledge that the larger eco
system already exists, and has for ages, Linked Data and the Web Of
Data; which use both #frag and 303 URIs.
2) "Tolerance: Be liberal in what you require but conservative in what
you do"
In the context of WebID 1.0, we must be liberal in what we require
(http(s): URIs), and conservative in what we do (publish and encourage
http(s) #frag URIs)
3) "Test of Independent Invention: If someone else had already invented
your system, would theirs work with yours?"
In the context of WebID 1.0, if 303 URIs are not allowed, then no, it
probably would not - this includes systems which have already existed
for a long time, many 303 URIs which refer to agents and deref to turtle
already exist, and many more will in the future too.
Implementation Conformance:
============================================
1) Will any implementations throw an error or fail if a WebID URI does
not include a #fragment? (no, and those that do will be ignored by most).
Specification Structure
============================================
1) If the specification is to be general, oriented at both producers and
consumers, then anything after a MUST which does not further refine the
constraint is a waste of time.
2) If the specification is to split in to guidance for consumers, and
separately for producers, then a "SHOULD use #frags" in the producer
section may make sense.
Interoperability:
============================================
There exists already a huge amount of data on the web, and a fair subset
of that is data describing agents, and URIs which refer to agents, both
#frag and 303.
LDP is in progress and we want to (and should) be interoperable with it,
but to preclude the many existing systems used in a read and write
scenario, from ftp through to sparql and via every custom system, and to
discount the billions of existing triples, makes no sense at all - why
is interoperability with LDP considered more important than
interoperability with the rest of the web of data?
Personal:
============================================
I will use and create WebIDs which are http(s) scheme URIs with a
#fragment, that's my choice, but I will also support your choice to use
303 URIs.
Sanity Check:
============================================
Interoperability Table:
---------------------------------------------------------
Systems | MUST be #frag | MUST be HTTP(S) URI
---------------------------------------------------------
use 303 URIs | no | yes
use #frag URIs | yes | yes
By this table it is clear that all "interoperability" arguments FOR a
#frag URI constraint fail instantly, so should be ignored.
Finally:
============================================
Remember I've argued at length for years against the use of 303 URIs,
investigated innumerable man hours in to hr14, and in to endless
conversations around the web and lists about hash vs slash, 303, frags
and everything related - right up to and including this email.
The issue is not about what I or we prefer, or think is right - the
issue is about tolerance and modularity.
Using #frag URIs has many benefits, who can dispute that? but adding a
#frag URI constraint excludes a *huge* section of the web of data, and
the linked data community. With NO, NONE, ZERO benefit.
Best,
Nathan