|
|
OAI-ORE |
On Aug 15, 5:42 am, "Robert Sanderson" <azarot...@gmail.com> wrote:
> "RDF syntax is based on a mathematical abstraction: an RDF graph is defined
In fact, HTTP already provides a generalized mechanism to clarify this
> However ... Note that the Aggregation is not a Named Graph, it's a subclass
If you believe me that the limits of representations are arbitrary,
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
> So, in order to talk about the description in RDF it needs a URI too, URI-R,
> Does that help?
> Rob
> It's not the AWWW that says this, but the fine print in the Named Graph
I'll add the Named Graph document to AWWW on my reading list. It
> specification:
> 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._____
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.
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
As far as I know, anything can be a resource according to HTTP. Does
> 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]
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?
I'm not doubting that these are separate resources. What I doubt is
> of dcmitypes:Collection.
> The Named Graph is the Resource Map.
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?
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?
> 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.
> 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)