> 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)

>> Does that help?

>> Rob