Re: AWWSW?

Jonathan Rees wrote:
> 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.

yes, that's what I mean :)

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

you /never/ GET the same representation, they are always anonymous.

   [] a :Representation .
   [] a :Representation .

How many representations? are they the same?

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

I have to disagree strongly, Hixie (and most people) use(s) URIs 
consistent with webarch, to refer to something that is consistent with 
all representations (nice way of putting it).

Evidence:

   HTML - Living Standard
   http://www.whatwg.org/specs/web-apps/current-work/multipage/

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

Nope, a URI /never/ refers to a representation, and any time anybody 
tries it creates inconsistencies.

Evidence:

 
http://check.rdfa.info/check?url=http://creativecommons.org/licenses/by/3.0/&version=1.0
The URI has been used to refer to the representation with 
xhv:stylesheet, xhv:alternate, core:translation, core:translationOf 
and the meaning is now inconsistent.

In FRBR terms the same URI is used to refer to an expression, a 
manifestation and an item.

  http://creativecommons.org/licenses/by/3.0/ refers to the expression 
(the License)
  http://creativecommons.org/licenses/by/3.0/deed.** refer to the 
manifestation(s) (the html documents)
  [] refers to the items (the representations)

The error is in RDFa 1.0 and the semantic web understanding, but it 
can easily be fixed, for example in the above license case:

  - Keep the License (expression) URI the same
  - Use the Content-Location to refer to the manifestation (html 
document) after a GET 200, if no CL is given then use a frag URI for 
the manifestation.
  - Use [] to refer to the representation, if you even want those 
triples to be generated.

The first is a global web arch level rule, likewise the last, and the 
middle one (manifestation) is user configurable, so long as the same 
name isn't used for both the expression and the manifestation.

If no URI for the manifestation is known, then associate it with a 
blank node.

Even when the subject isn't explicitly set, it can be determined with 
even the simplest 'domain' understanding of the properties/relations.

  - stylesheet and alternate have domain :Representation (or Item)
  - core:translation(Of) has a domain of :Manifestation (assuming it 
should also be transitive like alternate)
  - everything else is a subclass of Resource.

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

Yup, always a blank node, and if you want to give it a name explicitly 
then you're going to have to describe it effectively (I'd say a 
representation is a Literal, self describing) - something like duri or 
tdb is what we really need here.. (I think I just heard Larry curse me 
from here lol!)

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

indeed

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

Hmm, I disagree, I contend that semweb webarch and "landing page" can 
all use URI the same way, and often do, and should - and that 
Representation and NetworkResource never have URIs (unless explicitly 
given as discussed above).

I'm preparing in more detail but pretty sure it'll be in a model and 
provable v soon.

Best,

Nathan

Received on Wednesday, 2 February 2011 14:24:29 UTC