Michael,
> * The role of URI-A will increase. It will be the "main"
> thing you link to. You're correct in that now, the roles of
> URI-A and URI-R are split, with some relations using URI-A
> and other relations using URI-R.
OK, I think that sounds like a positive move. As much as is possible,
things should be talking about aggregations rather than ReMs - so, for
example, the <link> from an AR to where it is aggregated should be of
the form ore:isAggregatedBy URI-A, and not just a pointer to the ReM.
> * URI-A and URI-R will both resolvable, and both
> will be discoverable from the other.
:staying positive: OK, that sounds good - there are certain things
that should be prescribed about URI-As and URI-Rs:
1) Any URI-A that includes a frag id, then the URI without the frag id
*must* be the URI-R (by extension, the URI-R must be resolvable).
2) The frag id should be allowed to be anything, not only #aggregation
(we are just talking about identified nodes in the ReM - as the ReM
must have an ore:describes, it can state what the indentifier is,
there is no need to enforce that it is a specific value).
3) For URI-As that do not include a frag id, they must be resolvable.
Additionally, they should (in an RFC sense) have an ore:isDescribedBy
link to URI-R. It should also be highly recommended that the
ore:isDescribedBy is contained in a Link: header, which is returned
via a HEAD call.
> * The frag id trick will be just 1 way to differentiate (as
> opposed to now where it is presented as the only
> way). The recommended (but not required) approach
> will be to use "cool URIs", either via content negotiation,
> 303 redirection, or other http tricks (the data model
> will remain agnostic).
This is where I start to get argumentative. I *like* the frag id
trick. It means that every URI-A that utilises it can be transformed
into the appropriate URI-R to retrieve the describing ReM without
making an additional request. That makes a significant performance
difference on traversing ReMs/ aggregations, and of course significant
scalability gains.
Furthermore, once you have a ReM serialization, then you [SHOULD] have
an identified node for the aggregation - so the frag id 'trick' always
comes for free with every ReM. Even if you assign a specific URI-A,
you will always have the URI-R#fragment URI-As that are
ore:analogousTo (or owl:sameAs) it.
The advantage of the distinct URI-A is that it separates it from the
URI-R of a particular ReM serialization, and in theory allows you to
more freely change the ReM serialization (so you can move from Atom to
RDF as your needs change, or offer both to satisfy the widest range of
clients). That sounds like it's attempting to sidestep an issue that
is going to occur anyway - once the URI-R is 'out there', it needs to
be supportable, even in the event that the serialization needs to
change.
In other words, there needs to be a fundamental acknowledgement that
the URI-R / ReM can assert that it has been dcterms:replacedBy - or
simply that it is ore:analogousTo - another serialization (and in the
analogous case, to identify that there is a preferred serialization
that clients should use if possible). It needs to formally be part of
the specification how clients are expected to handle the presence of
multiple serializations, and what to do in the case that any are
deprecated (and indeed what publishers should be doing in those
circumstances for the clients to behave properly).
And once you deal with the multiple serialization / deprecation issue,
the advantages of URI-As being entirely separate from URI-Rs becomes
rather negligible, and when weighing up URI minting, and performance/
scalability concerns, most people would (imho) be well advised to
simply use the frag id trick.
G
