"An Aggregation does not have a representation..."
"the Aggregation URI A-1 must yield or lead to a Resource Map when
dereferenced."
Is this still the current thinking? If so, what's wrong with Resource
Maps being accepted as representations of the Aggregation?
I understand that a Resource Map is a description of an Aggregation
and not the Aggregation itself. This is true in the same sense that a
metadata record is not the same as a book. Nevertheless, it is fair to
say that a metadata record is a reasonable representation of a book.
If this was accepted, the questionable reference to an Aggregation
being a "non-information resource" could be dropped.
On Thu, Aug 14, 2008 at 08:48:47AM -0700, Jeff Young wrote: > I'm trying to put together a UML class diagram for ORE, and I'm > puzzled by these statements in section 3.1 of the "ORE-User Guide - > Primer":
> "An Aggregation does not have a representation..." > "the Aggregation URI A-1 must yield or lead to a Resource Map when > dereferenced."
> Is this still the current thinking? If so, what's wrong with Resource > Maps being accepted as representations of the Aggregation?
Well, this is a difference between English and the Architecture of the World Wide Web [AWWW] document. In English I think one could reasonably say that the Resource Map is a representation of an Aggregation. However, in the language of AWWW there is no bitstream for resource A-1 obtained via content negotiation so no representation. One does get either redirected to resource R-1 from which a representation is available, or -- as a shortcut -- one gets a represenation of R-1 back with a header saying that is is from R-1 and not from A-1.
> I understand that a Resource Map is a description of an Aggregation > and not the Aggregation itself. This is true in the same sense that a > metadata record is not the same as a book. Nevertheless, it is fair to > say that a metadata record is a reasonable representation of a book.
> If this was accepted, the questionable reference to an Aggregation > being a "non-information resource" could be dropped.
I think we will drop the information resource and non-information resource terminology as it just muddies the water.
Thanks for the feedback Simeon. I admit that I need to review AWWW and
will do so ASAP.
On Aug 14, 3:49 pm, Simeon Warner <sim...@cs.cornell.edu> wrote:
> Well, this is a difference between English and the Architecture of the
> World Wide Web [AWWW] document. In English I think one could
> reasonably say that the Resource Map is a representation of an
> Aggregation. However, in the language of AWWW there is no bitstream
> for resource A-1 obtained via content negotiation so no
> representation.
I can believe that AWWW recognizes the possibility of resources
without bitstreams, but I will be surprised if it dictates that an RDF
graph is such a resource. It's difficult to imagine why a set of
triples can't be a content-negotiable resource.
> One does get either redirected to resource R-1 from
> which a representation is available, or -- as a shortcut -- one gets a
> represenation of R-1 back with a header saying that is is from R-1 and
> not from A-1.
It's also hard for me to imagine why an HTTP redirect shouldn't be
understood as a type of resource representation. I'd have to look
closer, but I don't recall anything in HTTP/1.1 that undermines this
interpretation. Maybe AWWW deals with this too. If so, I fear that it
is splitting hairs that are already too thin and obscure.
> Thanks for the feedback Simeon. I admit that I need to review AWWW and > will do so ASAP.
> On Aug 14, 3:49 pm, Simeon Warner <sim...@cs.cornell.edu> wrote:
>> Well, this is a difference between English and the Architecture of >> the >> World Wide Web [AWWW] document. In English I think one could >> reasonably say that the Resource Map is a representation of an >> Aggregation. However, in the language of AWWW there is no bitstream >> for resource A-1 obtained via content negotiation so no >> representation.
> I can believe that AWWW recognizes the possibility of resources > without bitstreams, but I will be surprised if it dictates that an RDF > graph is such a resource. It's difficult to imagine why a set of > triples can't be a content-negotiable resource.
The statements which asserted on the RDF Resource represented by these URI describe various features of the Map itself rather than the Aggregation it is naming. Specifically, creation and modification Timestamps and the service which created the entire Resource Map.
>> One does get either redirected to resource R-1 from >> which a representation is available, or -- as a shortcut -- one >> gets a >> represenation of R-1 back with a header saying that is is from R-1 >> and >> not from A-1.
> It's also hard for me to imagine why an HTTP redirect shouldn't be > understood as a type of resource representation. I'd have to look > closer, but I don't recall anything in HTTP/1.1 that undermines this > interpretation. Maybe AWWW deals with this too. If so, I fear that it > is splitting hairs that are already too thin and obscure.
Interestingly, if you look at the output of the TBL's Tabulator extension for Firefox, most of the entire content negotiation request interaction is represented in RDF, thus asserting, this negotiation of the following request is in fact a capture-able itself as also a set of resources.
Cheers, Mark
~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage
On Fri, Aug 15, 2008 at 1:49 AM, Jeff Young <jyoung.o...@gmail.com> wrote: > I can believe that AWWW recognizes the possibility of resources > without bitstreams, but I will be surprised if it dictates that an RDF > graph is such a resource. It's difficult to imagine why a set of > triples can't be a content-negotiable resource.
It's not the AWWW that says this, but the fine print in the Named Graph specification:
"RDF syntax is based on a mathematical abstraction: an RDF graph is defined as a set of triples. These graphs are represented by documents which can be retrieved from URIs on the Web. Often these URIs are also used as a name for the graph, for example with an owl:imports. _____To avoid confusion between these two usages we distinguish between Named Graphs and the RDF graph that the Named Graph encodes or represents._____ A Named Graph is an entity with two functions name and rdfgraph defined on it which determine respectively its name, which is a URI , and the RDF graph that it encodes or represents. These functions assign a unique name and RDF graph to each Named Graph, but Named Graphs may have other properties; and named graphs may be concrete resources rather than set-theoretic abstractions." [ __ emphasis added]
However ... Note that the Aggregation is not a Named Graph, it's a subclass of dcmitypes:Collection. The Named Graph is the Resource Map.
I agree that a metadata record is a reasonable (summary) representation of an object, however that's not the model that the AWWW (sometimes rather clumsily) gives us. Instead, we have a Collection of Resources (the Aggregation) which needs an identifier. We then currently describe that Collection using a Named Graph called a Resource Map, but there's no reason that other people couldn't re-use the Aggregation identifier and describe it with another format. It would be outside the scope of ORE, but a perfectly valid re-use of the URI coined for the aggregation. When we assert statements about the aggregation, it's the abstract 'work' if you like, not the specific set of triples which we currently use to describe it.
So, in order to talk about the description in RDF it needs a URI too, URI-R, which is what makes it a Named Graph rather than just a bunch of triples. And where better to get a representation of that graph than from its URI! Thus we have the redirection mechanism, as per AWWW in order to get from the Aggregation (Collection, Work, Abstract Item of Interest) to the Resource Map (Description, Named Graph, Concrete Representation)
If this is the Aggregation URI, which the rdf claims it to be, then it should redirect to a resource map. Currently it presents an HTML page. Don't worry, there's an easy solution:
Embed RDFa in the HTML which is presented at what is now URI-A. It thus becomes a resource map. Then change the aggregation URI to URI-A#aggregation.
On Aug 15, 5:42 am, "Robert Sanderson" <azarot...@gmail.com> wrote:
> It's not the AWWW that says this, but the fine print in the Named Graph
> specification:
> "RDF syntax is based on a mathematical abstraction: an RDF graph is defined
> as a set of
> triples. These graphs are represented by documents which can be retrieved
> from URIs
> on the Web. Often these URIs are also used as a name for the graph, for
> example with
> an owl:imports. _____To avoid confusion between these two usages we
> distinguish between
> Named Graphs and the RDF graph that the Named Graph encodes or
> represents._____
I'll add the Named Graph document to AWWW on my reading list. It
worries me that I have to dig so deep, though, to understand why
HTTP's resource/representation model isn't adequate here. The
confusion being referred to is presumably caused by the fact that in
HTTP representations are typically resources in their own right. They
seem to be saying that people can't tell the difference and therefore
RDF needs to invent a competing model to clarify the problem.
In fact, HTTP already provides a generalized mechanism to clarify this
difference: the 300 (Multiple Choices) status. The big missing piece
is a specification for the response body, which can be community-
specific and even RDF-enriched. In reverse, the best mechanism for
tracing backward from representation to resource is still unclear to
me, but this problem doesn't seem so overwhelming that I would be
happy to chuck HTTP's generalized resource/representation model in
favor of the Named Graphs model.
> A Named Graph is an entity with two functions name and rdfgraph defined on
> it which
> determine respectively its name, which is a URI , and the RDF graph that it
> encodes
> or represents. These functions assign a unique name and RDF graph to each
> Named
> Graph, but Named Graphs may have other properties; and named graphs may be
> concrete
> resources rather than set-theoretic abstractions." [ __ emphasis added]
As far as I know, anything can be a resource according to HTTP. Does
RDF disagree with this liberalism? Perhaps the Named Graph authors
want to define "set-theoretic abstractions" as a class of "entities"
that isn't allowed to be represented in HTTP as a resource?
> However ... Note that the Aggregation is not a Named Graph, it's a subclass
> of dcmitypes:Collection.
> The Named Graph is the Resource Map.
I'm not doubting that these are separate resources. What I doubt is
the need to say "An Aggregation does not have a representation". Why
can't the Resource Map be accepted as a representation of the
aggregation? It's already returning it in response to the
Aggregation's URI. It's disconcerting to have an Aggregation URI that
is "without a representation" respond on demand with something that is
indistinguishable from a representation. Where is the line drawn
between what is allowed to be a representation, and what isn't? I'm
pretty sure it isn't defined in HTTP. RDF doesn't assume the HTTP data
model, so it can't be there. Is it the Named Graph authors? Is it ORE?
If you believe me that the limits of representations are arbitrary,
why not allow the Aggregation URI to return other types of responses
according to content-negotiation principles? Is ORE's concept of
Aggregations limited to its particular use cases, or does it extend
beyond into reality itself? Why be greedy here?
Sorry, but I need to stop here for now. My brain is fried.
> I agree that a metadata record is a reasonable (summary) representation of
> an object, however that's not the model that the AWWW (sometimes rather
> clumsily) gives us. Instead, we have a Collection of Resources (the
> Aggregation) which needs an identifier. We then currently describe that
> Collection using a Named Graph called a Resource Map, but there's no reason
> that other people couldn't re-use the Aggregation identifier and describe it
> with another format. It would be outside the scope of ORE, but a perfectly
> valid re-use of the URI coined for the aggregation. When we assert
> statements about the aggregation, it's the abstract 'work' if you like, not
> the specific set of triples which we currently use to describe it.
> So, in order to talk about the description in RDF it needs a URI too, URI-R,
> which is what makes it a Named Graph rather than just a bunch of triples.
> And where better to get a representation of that graph than from its URI!
> Thus we have the redirection mechanism, as per AWWW in order to get from the
> Aggregation (Collection, Work, Abstract Item of Interest) to the Resource
> Map (Description, Named Graph, Concrete Representation)
We are following the directions given in the W3C "Cool URIs for the semantic web" document when it comes to e.g. the HTTP 303 from uri-a to uri-r. And the same approaches listed there are also promoted in the Linked Data effort.
Herbert
Sent from my iPhone
On Aug 15, 2008, at 14:06, Jeff Young <jyoung.o...@gmail.com> wrote:
> On Aug 15, 5:42 am, "Robert Sanderson" <azarot...@gmail.com> wrote: >> It's not the AWWW that says this, but the fine print in the Named >> Graph >> specification:
>> "RDF syntax is based on a mathematical abstraction: an RDF graph is >> defined >> as a set of >> triples. These graphs are represented by documents which can be >> retrieved >> from URIs >> on the Web. Often these URIs are also used as a name for the graph, >> for >> example with >> an owl:imports. _____To avoid confusion between these two usages we >> distinguish between >> Named Graphs and the RDF graph that the Named Graph encodes or >> represents._____
> I'll add the Named Graph document to AWWW on my reading list. It > worries me that I have to dig so deep, though, to understand why > HTTP's resource/representation model isn't adequate here. The > confusion being referred to is presumably caused by the fact that in > HTTP representations are typically resources in their own right. They > seem to be saying that people can't tell the difference and therefore > RDF needs to invent a competing model to clarify the problem.
> In fact, HTTP already provides a generalized mechanism to clarify this > difference: the 300 (Multiple Choices) status. The big missing piece > is a specification for the response body, which can be community- > specific and even RDF-enriched. In reverse, the best mechanism for > tracing backward from representation to resource is still unclear to > me, but this problem doesn't seem so overwhelming that I would be > happy to chuck HTTP's generalized resource/representation model in > favor of the Named Graphs model.
>> A Named Graph is an entity with two functions name and rdfgraph >> defined on >> it which >> determine respectively its name, which is a URI , and the RDF graph >> that it >> encodes >> or represents. These functions assign a unique name and RDF graph >> to each >> Named >> Graph, but Named Graphs may have other properties; and named graphs >> may be >> concrete >> resources rather than set-theoretic abstractions." [ __ emphasis >> added]
> As far as I know, anything can be a resource according to HTTP. Does > RDF disagree with this liberalism? Perhaps the Named Graph authors > want to define "set-theoretic abstractions" as a class of "entities" > that isn't allowed to be represented in HTTP as a resource?
>> However ... Note that the Aggregation is not a Named Graph, it's a >> subclass >> of dcmitypes:Collection. >> The Named Graph is the Resource Map.
> I'm not doubting that these are separate resources. What I doubt is > the need to say "An Aggregation does not have a representation". Why > can't the Resource Map be accepted as a representation of the > aggregation? It's already returning it in response to the > Aggregation's URI. It's disconcerting to have an Aggregation URI that > is "without a representation" respond on demand with something that is > indistinguishable from a representation. Where is the line drawn > between what is allowed to be a representation, and what isn't? I'm > pretty sure it isn't defined in HTTP. RDF doesn't assume the HTTP data > model, so it can't be there. Is it the Named Graph authors? Is it ORE?
> If you believe me that the limits of representations are arbitrary, > why not allow the Aggregation URI to return other types of responses > according to content-negotiation principles? Is ORE's concept of > Aggregations limited to its particular use cases, or does it extend > beyond into reality itself? Why be greedy here?
> Sorry, but I need to stop here for now. My brain is fried.
> Jeff
>> I agree that a metadata record is a reasonable (summary) >> representation of >> an object, however that's not the model that the AWWW (sometimes >> rather >> clumsily) gives us. Instead, we have a Collection of Resources (the >> Aggregation) which needs an identifier. We then currently describe >> that >> Collection using a Named Graph called a Resource Map, but there's >> no reason >> that other people couldn't re-use the Aggregation identifier and >> describe it >> with another format. It would be outside the scope of ORE, but a >> perfectly >> valid re-use of the URI coined for the aggregation. When we assert >> statements about the aggregation, it's the abstract 'work' if you >> like, not >> the specific set of triples which we currently use to describe it.
>> So, in order to talk about the description in RDF it needs a URI >> too, URI-R, >> which is what makes it a Named Graph rather than just a bunch of >> triples. >> And where better to get a representation of that graph than from >> its URI! >> Thus we have the redirection mechanism, as per AWWW in order to get >> from the >> Aggregation (Collection, Work, Abstract Item of Interest) to the >> Resource >> Map (Description, Named Graph, Concrete Representation)
> We are following the directions given in the W3C "Cool URIs for the
> semantic web" document when it comes to e.g. the HTTP 303 from uri-a
> to uri-r. And the same approaches listed there are also promoted in
> the Linked Data effort.
> Herbert
> Sent from my iPhone
> On Aug 15, 2008, at 14:06, Jeff Young <jyoung.o...@gmail.com> wrote:
> > On Aug 15, 5:42 am, "Robert Sanderson" <azarot...@gmail.com> wrote:
> >> It's not the AWWW that says this, but the fine print in the Named
> >> Graph
> >> specification:
> >> "RDF syntax is based on a mathematical abstraction: an RDF graph is
> >> defined
> >> as a set of
> >> triples. These graphs are represented by documents which can be
> >> retrieved
> >> from URIs
> >> on the Web. Often these URIs are also used as a name for the graph,
> >> for
> >> example with
> >> an owl:imports. _____To avoid confusion between these two usages we
> >> distinguish between
> >> Named Graphs and the RDF graph that the Named Graph encodes or
> >> represents._____
> > I'll add the Named Graph document to AWWW on my reading list. It
> > worries me that I have to dig so deep, though, to understand why
> > HTTP's resource/representation model isn't adequate here. The
> > confusion being referred to is presumably caused by the fact that in
> > HTTP representations are typically resources in their own right. They
> > seem to be saying that people can't tell the difference and therefore
> > RDF needs to invent a competing model to clarify the problem.
> > In fact, HTTP already provides a generalized mechanism to clarify this
> > difference: the 300 (Multiple Choices) status. The big missing piece
> > is a specification for the response body, which can be community-
> > specific and even RDF-enriched. In reverse, the best mechanism for
> > tracing backward from representation to resource is still unclear to
> > me, but this problem doesn't seem so overwhelming that I would be
> > happy to chuck HTTP's generalized resource/representation model in
> > favor of the Named Graphs model.
> >> A Named Graph is an entity with two functions name and rdfgraph
> >> defined on
> >> it which
> >> determine respectively its name, which is a URI , and the RDF graph
> >> that it
> >> encodes
> >> or represents. These functions assign a unique name and RDF graph
> >> to each
> >> Named
> >> Graph, but Named Graphs may have other properties; and named graphs
> >> may be
> >> concrete
> >> resources rather than set-theoretic abstractions." [ __ emphasis
> >> added]
> > As far as I know, anything can be a resource according to HTTP. Does
> > RDF disagree with this liberalism? Perhaps the Named Graph authors
> > want to define "set-theoretic abstractions" as a class of "entities"
> > that isn't allowed to be represented in HTTP as a resource?
> >> However ... Note that the Aggregation is not a Named Graph, it's a
> >> subclass
> >> of dcmitypes:Collection.
> >> The Named Graph is the Resource Map.
> > I'm not doubting that these are separate resources. What I doubt is
> > the need to say "An Aggregation does not have a representation". Why
> > can't the Resource Map be accepted as a representation of the
> > aggregation? It's already returning it in response to the
> > Aggregation's URI. It's disconcerting to have an Aggregation URI that
> > is "without a representation" respond on demand with something that is
> > indistinguishable from a representation. Where is the line drawn
> > between what is allowed to be a representation, and what isn't? I'm
> > pretty sure it isn't defined in HTTP. RDF doesn't assume the HTTP data
> > model, so it can't be there. Is it the Named Graph authors? Is it ORE?
> > If you believe me that the limits of representations are arbitrary,
> > why not allow the Aggregation URI to return other types of responses
> > according to content-negotiation principles? Is ORE's concept of
> > Aggregations limited to its particular use cases, or does it extend
> > beyond into reality itself? Why be greedy here?
> > Sorry, but I need to stop here for now. My brain is fried.
> > Jeff
> >> I agree that a metadata record is a reasonable (summary)
> >> representation of
> >> an object, however that's not the model that the AWWW (sometimes
> >> rather
> >> clumsily) gives us. Instead, we have a Collection of Resources (the
> >> Aggregation) which needs an identifier. We then currently describe
> >> that
> >> Collection using a Named Graph called a Resource Map, but there's
> >> no reason
> >> that other people couldn't re-use the Aggregation identifier and
> >> describe it
> >> with another format. It would be outside the scope of ORE, but a
> >> perfectly
> >> valid re-use of the URI coined for the aggregation. When we assert
> >> statements about the aggregation, it's the abstract 'work' if you
> >> like, not
> >> the specific set of triples which we currently use to describe it.
> >> So, in order to talk about the description in RDF it needs a URI
> >> too, URI-R,
> >> which is what makes it a Named Graph rather than just a bunch of
> >> triples.
> >> And where better to get a representation of that graph than from
> >> its URI!
> >> Thus we have the redirection mechanism, as per AWWW in order to get
> >> from the
> >> Aggregation (Collection, Work, Abstract Item of Interest) to the
> >> Resource
> >> Map (Description, Named Graph, Concrete Representation)
On Aug 14, 3:49 pm, Simeon Warner <sim...@cs.cornell.edu> wrote:
> > "An Aggregation does not have a representation..."
> > "the Aggregation URI A-1 must yield or lead to a Resource Map when
> > dereferenced."
> > Is this still the current thinking? If so, what's wrong with Resource
> > Maps being accepted as representations of the Aggregation?
> Well, this is a difference between English and the Architecture of the
> World Wide Web [AWWW] document.
I think I see the source of my confusion now. This isn't the
difference between English and AWWW et al. It's the difference between
HTTP and those other things. From an HTTP perspective, a Resource Map
would make for a perfectly reasonable representation. If the documents
that have been cited so far explain this somewhere I might accept it,
although it is damned confusing of them to redefine words like
"representation" that way.
Sorry. Let me admit that this sentence from my last message doesn't
add up:
> From an HTTP perspective, a Resource Map
> would make for a perfectly reasonable representation.
I understand that a Resource Map is not a representation, it is a
resource that has representations. I still suspect there is a point to
what I was saying, but I'm afraid that this sentence might permanently
undermine it. If I'm lucky, I'll go insane before I have time to
reword it. ;-)
On Fri, Aug 15, 2008 at 06:17:24PM -0700, Jeff Young wrote: > On Aug 14, 3:49?pm, Simeon Warner <sim...@cs.cornell.edu> wrote: > > > "An Aggregation does not have a representation..." > > > "the Aggregation URI A-1 must yield or lead to a Resource Map when > > > dereferenced."
> > > Is this still the current thinking? If so, what's wrong with Resource > > > Maps being accepted as representations of the Aggregation?
> > Well, this is a difference between English and the Architecture of the > > World Wide Web [AWWW] document.
> I think I see the source of my confusion now. This isn't the > difference between English and AWWW et al. It's the difference between > HTTP and those other things. From an HTTP perspective, a Resource Map > would make for a perfectly reasonable representation. If the documents > that have been cited so far explain this somewhere I might accept it, > although it is damned confusing of them to redefine words like > "representation" that way. On Fri, Aug 15, 2008 at 07:28:10PM -0700, Jeff Young wrote: > Sorry. Let me admit that this sentence from my last message doesn't > add up:
> > From an HTTP perspective, a Resource Map > > would make for a perfectly reasonable representation.
> I understand that a Resource Map is not a representation, it is a > resource that has representations. I still suspect there is a point to > what I was saying, but I'm afraid that this sentence might permanently > undermine it. If I'm lucky, I'll go insane before I have time to > reword it. ;-)
I think this is why we (try to) avoid use of the word "representation" in the ORE docs except in the strict web architecture sense, e.g when describing the whe web architecture at http://www.openarchives.org/ore/0.9/primer.html#Web_Arch.
The fundamental reason why we don't have Aggregation == resource and Resource Map == representation is that we think they both need to have identifiers so that we can talk about them. In the web architecture, resources have URIs as identifiers but representions don't have have their own id (they are determined/"identified" by the resource URI, time, request info, phase of moon, etc.).
On Aug 18, 9:02 am, Simeon Warner <sim...@cs.cornell.edu> wrote:
> I think this is why we (try to) avoid use of the word "representation"
> in the ORE docs except in the strict web architecture sense, e.g when
> describing the whe web architecture athttp://www.openarchives.org/ore/0.9/primer.html#Web_Arch.
> The fundamental reason why we don't have Aggregation == resource and
> Resource Map == representation is that we think they both need to have
> identifiers so that we can talk about them. In the web architecture,
> resources have URIs as identifiers but representions don't have have
> their own id (they are determined/"identified" by the resource URI,
> time, request info, phase of moon, etc.).
The belief that "representations don't have their own id" seems to be
the root of the problem here. In HTTP, representations CAN have their
own identifiers (URIs) and thus can be addressed individually. As
evidence, the Content-Location header exists to notify a client of
this fact (http://tools.ietf.org/html/rfc2616#section-14.14). The
possibility of representation identifiers is even clearer in the case
of 300 Multiple Choices (http://tools.ietf.org/html/ rfc2616#section-10.3.1).
The domain model for ORE is still unclear to me, but on this one point
it seems like some heavyweight sources are being cited to work around
a relatively simple confusion. Somehow this workaround has come full-
circle and produced a resource without a representation that resolves
to a response that is indistinguishable from a representation. This
circularity implies that there are some concepts in ORE that can be
factored out.
> The belief that "representations don't have their own id" seems to be
> the root of the problem here. In HTTP, representations CAN have their
> own identifiers (URIs) and thus can be addressed individually. As
> evidence, the Content-Location header exists to notify a client of
> this fact (http://tools.ietf.org/html/rfc2616#section-14.14). The
> possibility of representation identifiers is even clearer in the case
> of 300 Multiple Choices (http://tools.ietf.org/html/ > rfc2616#section-10.3.1).
That is where there is a discrepancy between RFC 2616 and AWW. In
the http RFC, representations can have their own URIs. The AWWW
seems to tip-toe around this. Consider:
That certainly appears to be a resource: it has a URI and when
dereferenced it returns a representation (or, more likely, a
"variant" in RFC-2616 terms).
and tell that the last two URIs identify possible representations
for the 1st URI. That means "http://foo.edu/bar.abc" is both a
resource in its own right *and* a representation for another
resource. Effectively, its both a 1st and 2nd class citizen. RFC
2616 doesn't directly address this apparent inconsistency of URIs
identifying both a resource and representation. Its perfectly
obvious and reasonable from an implementation point of view, but
its really non-sensical from a modeling point of view.
The AWWW + friends introduce the concepts of "information resource"
(i.e., web things like html and pdf) and "non-information resource"
(i.e., real world things like cars and sandwiches) and 303 redirects
(which can be thought of as a generalized version of http content
negotiation as defined in RFC-2295). IMO, this is the opposite of
the above: it makes sense from a modeling point of view but is silly
from an implementation point of view ("so the only thing this URI
will *ever* do is redirect me to this other URI? ok...")
> The domain model for ORE is still unclear to me, but on this one point
> it seems like some heavyweight sources are being cited to work around
> a relatively simple confusion. Somehow this workaround has come full-
> circle and produced a resource without a representation that resolves
> to a response that is indistinguishable from a representation. This
> circularity implies that there are some concepts in ORE that can be
> factored out.
> > The belief that "representations don't have their own id" seems to be > > the root of the problem here. In HTTP, representations CAN have their > > own identifiers (URIs) and thus can be addressed individually. As > > evidence, the Content-Location header exists to notify a client of > > this fact (http://tools.ietf.org/html/rfc2616#section-14.14). The > > possibility of representation identifiers is even clearer in the case > > of 300 Multiple Choices (http://tools.ietf.org/html/ > > rfc2616#section-10.3.1).
> That is where there is a discrepancy between RFC 2616 and AWW. In > the http RFC, representations can have their own URIs. The AWWW > seems to tip-toe around this. Consider:
> That certainly appears to be a resource: it has a URI and when > dereferenced it returns a representation (or, more likely, a > "variant" in RFC-2616 terms).
> and tell that the last two URIs identify possible representations > for the 1st URI. That means "http://foo.edu/bar.abc" is both a > resource in its own right *and* a representation for another > resource. Effectively, its both a 1st and 2nd class citizen. RFC > 2616 doesn't directly address this apparent inconsistency of URIs > identifying both a resource and representation. Its perfectly > obvious and reasonable from an implementation point of view, but > its really non-sensical from a modeling point of view.
> The AWWW + friends introduce the concepts of "information resource" > (i.e., web things like html and pdf) and "non-information resource" > (i.e., real world things like cars and sandwiches) and 303 redirects > (which can be thought of as a generalized version of http content > negotiation as defined in RFC-2295). IMO, this is the opposite of > the above: it makes sense from a modeling point of view but is silly > from an implementation point of view ("so the only thing this URI > will *ever* do is redirect me to this other URI? ok...")
There are numerous circumstances when making a distinction between a resource and a representation is simply not all that useful, and thus the idea that "it is perfectly obvious and reasonable from an implementation point of view" ought to win the day. I fear that drawing the line between those too strongly (especially since content negotiation is by no means always practical or operational) may be dangerous.
That probably sounds heretical, but too much emphasis on "modeling" as opposed to implementation may put too much emphasis on the producer and not enough on the consumer. A consumer (i.e., implementation) ought to be able to decide for itself, thus allowing for evolution, serendipitious reuse, etc. The "contract" that a resource map producer asserts ought to be as "secular" as possible -- "hypermedia as the engine of state" -- as the REST principles state. ORE is really about asserting the "state" of a set of resources, as embodied in each resource's relationship with other resources and all of it described by links.
> > The domain model for ORE is still unclear to me, but on this one point > > it seems like some heavyweight sources are being cited to work around > > a relatively simple confusion. Somehow this workaround has come full- > > circle and produced a resource without a representation that resolves > > to a response that is indistinguishable from a representation. This > > circularity implies that there are some concepts in ORE that can be > > factored out.
As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else walks".
Well ... in my implementation experience[1], the current specifications are very readily implementable. In fact the Atom serialisation was by FAR the hardest part, to the point of total nightmare to get right.
The difference between URI-A and URI-R is very easy to implement, and redirects in most environments are pretty trivial. Actual content negotiation is trickier (both client and server), which is why we can also have ore:isDescribedBy to point at other resource maps.
The problem with implementations deciding things for themselves rather than faithfully following a clear and easy to code set of specifications is a *lack* of interoperability when two implementers have very clear and different intuitions.
On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <pke...@mail.utexas.edu> wrote: > There are numerous circumstances when making a distinction between a > resource and a representation is simply not all that useful, and thus the > idea that "it is perfectly obvious and reasonable from an implementation > point of view" ought to win the day. I fear that drawing the line between > those too strongly (especially since content negotiation is by no means > always practical or operational) may be dangerous.
> That probably sounds heretical, but too much emphasis on "modeling" as > opposed to implementation may put too much emphasis on the producer and not > enough on the consumer. A consumer (i.e., implementation) ought to be able > to decide for itself, thus allowing for evolution, serendipitious reuse, > etc. The "contract" that a resource map producer asserts ought to be as > "secular" as possible -- "hypermedia as the engine of state" -- as the REST > principles state. ORE is really about asserting the "state" of a set of > resources, as embodied in each resource's relationship with other resources > and all of it described by links.
On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <azarot...@gmail.com>wrote:
> As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else > walks".
> Well ... in my implementation experience[1], the current specifications are > very readily implementable. In fact the Atom serialisation was by FAR the > hardest part, to the point of total nightmare to get right.
But would some or all of that difficulty be cleared up by the new Atom serialization proposal ( http://www.openarchives.org/ore/documents/atom_revision_20080801.html)? The new serialization seems like it would be easy to implement and from the client side easier to make use of (in many cases) than an RDF-based serialization.
> The difference between URI-A and URI-R is very easy to implement, and > redirects in most environments are pretty trivial. Actual content > negotiation is trickier (both client and server), which is why we can also > have ore:isDescribedBy to point at other resource maps.
> The problem with implementations deciding things for themselves rather than > faithfully following a clear and easy to code set of specifications is a > *lack* of interoperability when two implementers have very clear and > different intuitions.
What I meant is that I fear a tight coupling between servers and clients vis-a-vis what is a representation and what is a resource instead of sticking with MIME types and hypermedia as the basis for the "contract" -- therein I see the benefit of a set of specifications in which atom:link@reland atom:category and such like are critical.
> On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <pke...@mail.utexas.edu>wrote:
>> There are numerous circumstances when making a distinction between a >> resource and a representation is simply not all that useful, and thus the >> idea that "it is perfectly obvious and reasonable from an implementation >> point of view" ought to win the day. I fear that drawing the line between >> those too strongly (especially since content negotiation is by no means >> always practical or operational) may be dangerous.
>> That probably sounds heretical, but too much emphasis on "modeling" as >> opposed to implementation may put too much emphasis on the producer and not >> enough on the consumer. A consumer (i.e., implementation) ought to be able >> to decide for itself, thus allowing for evolution, serendipitious reuse, >> etc. The "contract" that a resource map producer asserts ought to be as >> "secular" as possible -- "hypermedia as the engine of state" -- as the REST >> principles state. ORE is really about asserting the "state" of a set of >> resources, as embodied in each resource's relationship with other resources >> and all of it described by links.
On Aug 18, 2:57 pm, MichaelNelson <RhodeWarri...@gmail.com> wrote:
> That is where there is a discrepancy between RFC 2616 and AWW. In
> the http RFC, representations can have their own URIs. The AWWW
> seems to tip-toe around this. Consider:
> That certainly appears to be a resource: it has a URI and when
> dereferenced it returns a representation (or, more likely, a
> "variant" in RFC-2616 terms).
As far as I can tell, the terms "representation" and "variant" are
interchangeable in HTTP.
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `varriant'. (http://tools.ietf.org/ html/rfc2616#section-1.3)
> and tell that the last two URIs identify possible representations
> for the 1st URI. That means "http://foo.edu/bar.abc" is both a
> resource in its own right *and* a representation for another
> resource. Effectively, its both a 1st and 2nd class citizen. RFC
> 2616 doesn't directly address this apparent inconsistency of URIs
> identifying both a resource and representation.
As I've been suggesting, this situation isn't as confusing as it
appears. HTTP defines mechanisms for the *server* to make these
assertions (e.g. HTTP headers or a 300 Multiple Choice entity body).
The fact that others may disagree with these assertions is a different
matter where an application/rdf+xml representation could clearly play
a role. We can also admit that servers frequently fail to use these
mechanisms, but it seems better to educate people about this oversight
than to invent a tunneled solution that involves a host of extraneous
concepts.
> Its perfectly
> obvious and reasonable from an implementation point of view, but
> its really non-sensical from a modeling point of view.
It's only non-sensical if you ignore the features of HTTP that are
designed to model it.
> The AWWW + friends introduce the concepts of "information resource"
> (i.e., web things like html and pdf) and "non-information resource"
> (i.e., real world things like cars and sandwiches) and 303 redirects
> (which can be thought of as a generalized version of http content
> negotiation as defined in RFC-2295). IMO, this is the opposite of
> the above: it makes sense from a modeling point of view but is silly
> from an implementation point of view ("so the only thing this URI
> will *ever* do is redirect me to this other URI? ok...")
From the modeling POV, the AWWW "information resource" concept is
being tunneled through HTTP despite the fact that HTTP already has a
model to deal with this particular situation. This seems to account
for the silliness you mention.
Note that I'm not saying that AWWW's purported concept of an
information resource without a representation doesn't have merit.
"info" URIs appear to be an example of this. What I'm suggesting is
that this AWWW concept can apparently be factored out in this case. If
it's too late to do that, that's one thing. OTOH, if there is a real
need for it that I'm not seeing, I would like to understand it.
> > The domain model for ORE is still unclear to me, but on this one point
> > it seems like some heavyweight sources are being cited to work around
> > a relatively simple confusion. Somehow this workaround has come full-
> > circle and produced a resource without a representation that resolves
> > to a response that is indistinguishable from a representation. This
> > circularity implies that there are some concepts in ORE that can be
> > factored out.
On Aug 18, 5:28 pm, "Robert Sanderson" <azarot...@gmail.com> wrote:
> As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else
> walks".
If you are saying that ORE has passed the Rubicon, I can accept that.
The fact that I am bogged down right out of the gate probably says
more about me than it does about ORE.
> Well ... in my implementation experience[1], the current specifications are
> very readily implementable.
I trust that ORE is easy to implement. It's just not clear to me yet
why it is necessary. I assume that this current thread is just me
stumbling out of the blocks. If my fumbling is a distraction, I will
understand and can try harder to work it out on my own.
> In fact the Atom serialisation was by FAR the
> hardest part, to the point of total nightmare to get right.
I am reluctant to share my suspicion about this since I haven't earned
the right yet. I encourage everyone to hit the delete button before
reading any farther.
My intuition is telling me that ORE Atom serialization problems are
related to the confusion about resource/representation, but I can't
back this up yet.
> The difference between URI-A and URI-R is very easy to implement, and
> redirects in most environments are pretty trivial. Actual content
> negotiation is trickier (both client and server), which is why we can also
> have ore:isDescribedBy to point at other resource maps.
Since ORE doesn't recognize the resource/representation model defined
by HTTP, it shouldn't be surprising that content-negotiation is
tricky. Tunneling resource/representation relationships in RDF is
certainly one alternative, but it comes at a steep cost to HTTP
interoperability.
> The problem with implementations deciding things for themselves rather than
> faithfully following a clear and easy to code set of specifications is a
> *lack* of interoperability when two implementers have very clear and
> different intuitions.
Again, I encourage everyone to hit the delete button before reading
farther. Chances are good that I am merely displaying my ignorance of
ORE.
At least some concepts in ORE appear to be tunneled over HTTP that
HTTP is capable of handling natively. The concepts of resource/
representation and content-negotiation appear to be likely candidates.
I would argue that tunneling generally reduces interoperability.
> On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <pke...@mail.utexas.edu> wrote:
> > There are numerous circumstances when making a distinction between a
> > resource and a representation is simply not all that useful, and thus the
> > idea that "it is perfectly obvious and reasonable from an implementation
> > point of view" ought to win the day. I fear that drawing the line between
> > those too strongly (especially since content negotiation is by no means
> > always practical or operational) may be dangerous.
> > That probably sounds heretical, but too much emphasis on "modeling" as
> > opposed to implementation may put too much emphasis on the producer and not
> > enough on the consumer. A consumer (i.e., implementation) ought to be able
> > to decide for itself, thus allowing for evolution, serendipitious reuse,
> > etc. The "contract" that a resource map producer asserts ought to be as
> > "secular" as possible -- "hypermedia as the engine of state" -- as the REST
> > principles state. ORE is really about asserting the "state" of a set of
> > resources, as embodied in each resource's relationship with other resources
> > and all of it described by links.- Hide quoted text -
> As far as I can tell, the terms "representation" and "variant" are
> interchangeable in HTTP.
> variant
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/ > html/rfc2616#section-1.3)
actually, the RFC makes a distinction: representations correspond
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
regardless, the AWWW abandons the "variant" vs. "representation"
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
> designed to model it.
but that's just it -- I don't think RFC-2616 adequately *models* what
is happening. nowhere does it explicitly state that:
even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
> As far as I can tell, the terms "representation" and "variant" are
> interchangeable in HTTP.
> variant
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/ > html/rfc2616#section-1.3)
actually, the RFC makes a distinction: representations correspond
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
regardless, the AWWW abandons the "variant" vs. "representation"
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
> designed to model it.
but that's just it -- I don't think RFC-2616 adequately *models* what
is happening. nowhere does it explicitly state that:
even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
> As far as I can tell, the terms "representation" and "variant" are
> interchangeable in HTTP.
> variant
> A resource may have one, or more than one, representation(s)
> associated with it at any given instant. Each of these
> representations is termed a `varriant'. (http://tools.ietf.org/ > html/rfc2616#section-1.3)
actually, the RFC makes a distinction: representations correspond
to resources that are subject to content negotiation. variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616. those entities only become variants
or
representations if there is more than one entity possible for a
resource.
although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.
regardless, the AWWW abandons the "variant" vs. "representation"
vs. "entity" distinction altogether. on one hand, the distinction
doesn't really matter. on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.
> It's only non-sensical if you ignore the features of HTTP that are
> designed to model it.
but that's just it -- I don't think RFC-2616 adequately *models* what
is happening. nowhere does it explicitly state that:
even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.
its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view. having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
less transaction).
(and it actually happens a lot -- Apache has implemented a version
of RFC-2295 since forever (which defines that you only get a 300
response only if you explicitly ask for it with a Negotiate: request
header) -- its just that few people witness it. client send various
Accept.*: request headers and the server responds with the correct
Vary:, TCN: and Alternates: response headers and few people actually
witness it. I mention this only b/c there is a prevailing belief
that content negotiation doesn't happen a lot -- it happens, but
people just don't see it b/c the client is not redirected (i.e.,
the URL in the toolbar doesn't change)).
the 303 generalized content negotiation does remove the de facto
restriction of occuring on the same server. That is conventionally
you can only do things of the form: http://foo/a --> http://foo/a.html.
with AWWW 303 style CN you can do: http://foo/a --> http://bar/a.
but this flexibility does cost you an extra http transaction.
of course, none of this changes your other, more salient points.
I just like to talk http. ;-)
> On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <azarot...@gmail.com>wrote:
>> As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else >> walks". >> Well ... in my implementation experience[1], the current specifications >> are very readily implementable. In fact the Atom serialisation was by FAR >> the hardest part, to the point of total nightmare to get right.
> But would some or all of that difficulty be cleared up by the new Atom > serialization proposal ( > http://www.openarchives.org/ore/documents/atom_revision_20080801.html)? > The new serialization seems like it would be easy to implement and from the > client side easier to make use of (in many cases) than an RDF-based > serialization.
Yes, the new specification makes it much easier, and seems much more in line with the way people actually *use* Atom. From the client side, you can now probably get by with a parser that only understands Atom, rather than one that also understands ORE's Atom spec.
That said, the inherent difficulty comes from using an RDF model underneath in order to serialise the RDF formats, and to allow for arbitrary triples, and then layering what is effectively an object model over top (with Aggregations, Resources, Resource Maps, Agents and so forth)
> What I meant is that I fear a tight coupling between servers and clients > vis-a-vis what is a representation and what is a resource instead of > sticking with MIME types and hypermedia as the basis for the "contract" -- > therein I see the benefit of a set of specifications in which atom:link@reland atom:category and such like are critical.
Yep. I think the new spec does a better job of re-using Atom's linking constructions appropriately (ob. disclaimer of authorship aside)
For the record, I think I understand the error of this earlier
statement. I won't go into the details because it's likely that no one
cares. If I've confused others by this sophistry the way I confused
myself, let me know and I can try to undo the damage.
Fortunately or unfortunately, this was a minor tangent to my main
confusion. I won't address that here, though.
Jeff
On Aug 15, 10:28 pm, Jeff Young <jyoung.o...@gmail.com> wrote:
> Sorry. Let me admit that this sentence from my last message doesn't
> add up:
> > From an HTTP perspective, a Resource Map
> > would make for a perfectly reasonable representation.
> I understand that a Resource Map is not a representation, it is a
> resource that has representations. I still suspect there is a point to
> what I was saying, but I'm afraid that this sentence might permanently
> undermine it. If I'm lucky, I'll go insane before I have time to
> reword it. ;-)
|
