[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
> What are the intended semantics where a resource denoted by
> http://www.parts-depot.com/parts has a Meta-Location: of
> http://www.parts-depot.com/parts and a Meta-About: of
> http://www.parts-depot.com/parts?
If I understand you correctly, this would be saying that the resource
contains its own metadata.
> One might want to declare more than one Meta-Location for a
> resource. How would that be handled, or is there a good reason to
> disallow a one to many relationship other than the fact that teeing
> up Meta-About with Meta-Location works well as long there's only one
> each?
>
> How does one determine which Meta-Location is authorative? [I'm
> assuming that it will be the one offered by the origin server of the
> resource question, but it's not stated anywhere.]
These two questions are related. We thought it best for a resource to
have one authoritive source of metadata. This is determined by the
Meta-Location header returned by the resource. Of course, if you have a
whole bunch of metadata documents you want associated with the resource
we would advocate having Meta-Location point to an RDDL document or
other such aggregation document type.
With respect to Meta-About, there is nothing stopping third parties from
creating their own metadata for a resource and pointing to it with the
Meta-About header. So while there is only one authoritive set of
metadata, there can be countless alternatives offered.
> What should an agent do when it only finds one header?
I'm not sure I understand this question. Most resources would only
provide one of the headers (unless you have meta data about meta data,
but I'm not sure how common that would be). The vast majority of
resources on the Internet are not metadata so they would at most have a
Meta-Location header.
> Are the values of the headers restricted to certain schemes, or are
> they generic URIs?
They are generic URLs.
> What I don't like about this proposal is the use of pairwise
> headers - if thee headers are interdependent modelling them otherwise
> strikes me as mildly brittle
I am not sure I understand your concern here. My guess is that we were
not clear that we were purposely allowing the publishing of metadata
about a resource without the resource having to know about it (i.e., the
non authoritative metadata). Hence the many to one relationship
possible between Meta-About and a resource. Does that help, or did I
miss what you were getting at here.
> .Btw, there's no support for design goal one in this proposal,
> since there's no way specified to share reputations, just raw
> descriptions. As it happens that's a good thing - mixing up
> reputation management with locating metadata about resources doesn't
> seem like a good idea. But I suggest dropping it as a goal nonetheless.
Yes, I think we agree here. Our purpose was to enable/facilitate
reputation managment by third parties not solve it ourselves.
Obviously, we need to rewrite the goal to make that clearer.
Thanks for your comments. They are appreciated.
David
|
