Re: AWWSW?

On Wed, Feb 2, 2011 at 8:50 AM, Nathan <nathan@webr3.org> wrote:
> Nathan wrote:
>>
>> To summarize where this leaves us at the minute, we have four classes of
>> things:
>>
>>  - Resource (can be named with a URI)

This is silly. Anything can be named with a URI.

>>  - NetworkResource (always unnamed)

Silly for same reason as above.  Even when you use a local name
('blank node' notation), you are naming.

Maybe you mean: Not usually possessing a global name; or not normally
given a name during normal operations; or not possessing a name that
will be understood out of context.

>>  - Representation (always unnamed)
>>  - RepresentationElement (always unnamed)
>
> and:
> - Message (always unnamed)

> I'd also suggest that by looking at every header used in http messages, we
> could set the domain of each accordingly such that some apply to the
> Message, some the Representation (if the message carries one), some the
> NetworkResource - and I'd be interested to see if any ever apply to a/the
> Resource (I've got a funny feeling the answer is no).

I think you're trying to get at the issue of embedded metadata. Of
course not all metadata is embedded and the two situations are quite
different in terms of how claims are checked and who is responsible
for them.

Embedded metadata in RDF is interesting because the *intended* subject
is usually the document in which it occurs, and this subject is
usually named by the base URI.  This is in conflict with using the
base URI as a name difference for what you GET, because you don't
always GET the same representation.

This is another turf war, and it can be resolved by letting either
side win. If URIs mean what they do in embedded metadata, then they
are pronouns, referring to different representations at different
times.  This is the way Hixie like to use URIs, I think. Alternately
URIs can refer to something that is consistent with all
representations, as in webarch.

There are two things to talk about, so in either design you need two
designations. If the URI refers to the representation, you need a
different way to talk about the representations generally. If the URI
refers to representations generally, you need a way to refer to the
subject of embedded metadata. I think you're looking for the latter.

You can't use a pronoun like thismessage: because it won't survive RDF
graph merging.

You can certainly use a local name (blank node). If you describe the
representation adequately then people (and machines) will know what
you're talking about. By construction the representation will be
accessible, so you don't need an actionable name, you just need to be
able to convince your reader that you intend to be talking about that
representation. That is, you need to "identify" it. A good way to do
this is with metadata. If the representation is in a 200 response, the
request URI and some of the headers (maybe ETag, or Date:, a
combination of others, whatever it takes to make it recognizably
unique) ought to do the trick - the problem is the same as for HTTP
caches.

Or you could put a unique id or tag: URI in the content and say the
blank node is the representation containing that unique id. Of course
there could be more than one such representation, so it would have to
have a golden ellipse drawn around it to make it special.

Hashes ought to help, as in UNF
(http://thedata.org/book/unf-version-5), but that depends on being
able to separate the content or message into what is hashed and the
hash.  XML has something like this, right?

I agree that NetworkResources also compete for use of the URI. That
would add a fifth contender for the spot (after webarch, landing page,
semweb, representation).  Hot property!

Jonathan

Received on Wednesday, 2 February 2011 13:44:35 UTC