See also: IRC log
<dbooth> jar: wanted to make a decision on the draft today, but can't with only two people on the call
<jar> let's look at this diagram: http://lists.w3.org/Archives/Public/public-awwsw/2011Apr/0045.html
<jar> the rhetorical question is: Can awww:representations have metadata such as DC, CC REL, FOAF, RDFS?
<jar> i.e. are we willing to use reprs. with those relations? TimBL & TAG would say no - I think - but not sure
<jar> the diagram reflects the way the report is currently written
<dbooth> dbooth: Diagram looks reasonable, but not needed for this document.
<dbooth> jar: The diagram explains the problem with the Ian Davis's proposal.
<dbooth> dbooth: I see nothing fundamentally wrong with Ian's proposal. It will cause problems for some apps and not others.
<dbooth> dbooth: so you feel that there has already been an expectation set in this community that there would not be ambiguity along this access (i.e., IR vs non-IR axis)?
<dbooth> jar: yes
<dbooth> dbooth: i think that's a legitimate complaint.
<jar> has nothing to do with IR vs. non-IR. it's whether the URI refers to the IR at that URI, or to something else
<dbooth> I think there would be debate about how firmly that expectation was established in the community. Some (I think) may claim that it has not been well established.
<dbooth> jar: it has succeeded so well that it is hard to find people against it -- see Cool URIs for SW, etc.
<jar> pedantic-web
<dbooth> dbooth: agreed.
<jar> 1. Reps are not IRs (TimBL)
<jar> 2. Metadata subjects ~ IRs
<jar> 3. Metadata can be true of reps (JAR)
Reading it - the nice picture :)
that diagram looks about right.
<jar> two problems with the diagram: what boxes are needed, and what they're called.
except for maybe that the metadata itself will likely have a URI with versions, representations, etc :)
the TAG will understand it, programmers won't.
but the programmers should be the *goal*.
<dbooth> jar: This document is to get the discussion goign w Giovanni, Ian, kingsley, etc.
<dbooth> harry: When they publish metadata, they need a clear, easy recipe.
Fielding way with resources being functions over representations in time...
type-token relationship
type-realization
share some abstract amount of information
"about" the same thing.
<dbooth> harry: Re "representation", there are different ways of thinking about it. Can also think of it as a type-token realization. Theyre' not manufactured randomly, but they're about the same thing.
<dbooth> jar: Like i say about metadata.
wonderful theoretical theory of semantic information
<dbooth> harry: I think that's timbl's intuition also.
<jar> http://www.w3.org/2001/tag/awwsw/ir-axioms/
ah I hvaen't seen that.
+1 as a separate document
<dbooth> dbooth: I think the CC license use case is the best one for motivating that discussion w Giovanni, Ian, Kingsley, etc.
Appendix 7
http://www.w3.org/2001/tag/awwsw/issue57/latest/#ir
<jar> move appendix 7 out to a separate document ?
1) Maybe merge that appendix
2) Move the glossary to back
1) Maybe merge into appendix another doc about IRs.
<dbooth> harry: I would want the following changes to make me happy: 1. merge appendix into another doc about IRs. 2. move glossary to the back.
<jar> if you didn't care about IRs, you'd just use 200, and skip 303
1) applicaton/rdf+xml (plus future RDF types that do not mix in with human-readable documents like HTML)
should just be assumed that the URI they are referring to in that document
is not the document itself.
That's the RDFa case.
<dbooth> harry: One option i'd like listed: doc of application/rdf+xml and future types that do not mix human-readable documents, should be taken as the the URI def
<jar> RDFa is different from rdf/xml
RDFa it makes perfect sense for that refer to the document.
<dbooth> harry: RDFa is different from rdf/xml because it mixes RDF and human doc.
<dbooth> jar: That's still a problem for CC license. I first have to GET the doc, and make sure that it is one of the RDF-only doc types.
So if the URI returns rdfa+html then you would assume that takes priority.
Can you make a normative algorithm for sorting this out
<dbooth> dbooth: if you get a mixed RDF+human doc type then it is potentially ambiguous.
<jar> algorithm: Do a GET , conneg for rdf/xml turtle manchester preferred
<jar> if you get rdf, then URI i sdefined by doc only
<jar> otherwise, URI refers to IR
but even if you got rdf/xml
via a conneg preference
then if those rdf/xml statements things like "dc:creator BenAdida"
then the interpretation of that staments, one thing would match would be the document
yes it could.
that's the risk of using model-theoretic interpretation in risk.
"dc:creator BenAdida"
so many documents that Ben Adida actually created.
accessibeVia
"accessibleVia"
retract 303
there should be more options
do not requrire .htaccess
1) add a vocabulary make it clear
2) make the MIME-types clearer
<dbooth> jar: Harry's proposal is covered in 5.6
<dbooth> jar: I'd like to see the proposal drafted as an actual algorithm.
My point is that 303 is only one way to make the distinguishment.
<jar> if you allow a definition AND a 200, you get wrong answers... so not just a question of providing "more ways"
For one instance, IR ->303-> IR
well if you got http://www.example.org -> www.example.org/document/index.html
"http://www.example.org" doesn't also just refer to a document or does it refer to Paris?
<dbooth> harry: Two more points about 303: 1. With 303 you could connect an IR to another IR, and there's no way of knowing whether that also doesn't just refer to a document.
http://www.example.org/document/index.html
inherently ambiguous
by nature of how 303 can be used
http://www.example.org/resource/Paris
<jar> i don't get it
is inherently ambiguous
http://www.example.org/document/Paris.html isn't.
so what does 303 gives you really
its also hard to index things like have status codes
<dbooth> http://www.example.org/resource/Paris --303--> http://www.example.org/document/Paris.html
<jar> the assumption for 303 is that if you get a 303 then it has no versions (not dereferenceable)
nothing says that "http://www.example.org/resource/Paris" is not an information resource
<jar> at that URI at least
<dbooth> dbooth: The 303 rule could be that the URI refers to the primarySubjectOf the document at the redirect URI
<jar> 200 enables metadata. if you don't enable particular metadata, you can't do 200. so, 404, 303, 100, etc instead
<dbooth> jar: 200 enables metadata, so if you want to prevent the metadata from being written, then you return 404 or 303.
www.example.org/resource/Paris and just rdf/xml documents.
thats that document somehow overrides to publish data
that could be solved by a normative argument.
<dbooth> harry: we might promote more RDF published by making it easier than requiring 303
<dbooth> jar: but there is a cost if we make an incompatible change -- existing metadata will be called into question.
<dbooth> ... Yes there's a benefit, but also a cost.
DC.terms
<dbooth> harry: I think the cost is not huge.
that you could make a normative algorithm
that says "given the space that can returned" figure out if it's an IR or not.
<dbooth> jar: It's not IR vs NIR, but *which* IR it is.
1) we need normative algorithm something like Web Linking
<dbooth> jar: we have the 303 guideline in place, but people like you and Ian are taking pot shots at it. how do we get process around this?
2) as regards 303, we need 2 or 3 more options
<dbooth> harry: 303 is a creative hack that is hurting deployment. my interest is in increasing deployment.
3) I would punt this at the RDF WG
it's already been chartered
<dbooth> jar: I'm concerned about the process. I want to dialog about this.
<dbooth> jar: TAG is willing to take issue-57 to rec track.
"s p o"
that means we're talking LISP don't interepret
"s p o" p2 o2
well, one way is to say
<dbooth> harry: Re quoting thing: tim says let's put an RDF graph in quotes.
if you want to talk about a document
and you want to be very clear
variant on notational scheme
"http://www.example.org/Paris"
talking about JUST the rdf statements themselves, and not their interpretation
<dbooth> ... Then if you want to talk about a doc, then we can quote the RDF graph to say that we're talking about that graph and not their interpretation.
<jar> [:accessibleVia "..."]
"http://www.example.org/Paris/document"
<dbooth> dbooth: Not always talking about RDF graph -- sometimes it's an HTML page you want to distinguish.
5.1 -> use quotes around URIs
will be used as a name URI of named graph
where the graph derferenced in a statement of RDF statements
currently the way you http://www.example.org/Paris ->http://www.example.org/Paris/document
currently the way you http://www.example.org/Paris ->http://www.example.org/Paris/data
http://www.example.org/Paris/data is the RDF name itself.
5.1 look at quoting mechanism
turn the document in latest version of 57
Rec should be FOR 303
not against 303
then explaining options to it
and then a normative algorithm that determines from the space interpretations gotten in consistent way
maybe fix fixed informaton resource -> representation
The data in the browser
did sometehing useful
joint task go named graph area
> - intention of who?
your talked a URI means or refers to.
What its minter or owner or person who created metadata what they *intend* it to me.
"discovery problem"
figure out what the community means.
<dbooth> dbooth: This is what http://dbooth.org/2009/lifecycle/ gets into.
"discovery problem"
XRD, Simple Web Discovery, Web Linking
fixed information resource
"fixed information resource" = "version of information resource"?
<dbooth> dbooth: If you get into "meaning", then you need to define what you mean by "meaning", and that's a lot more difficult. But if we just talk about the *mechanics* of getting a definition, then we don't need to get into it.
#could be considered an indirection
RDFa crawls of Yahoo!
Facebook is brought up with RDFa
Hixie brings in HTML5 against using URIs in prefixes in general.
Hixie's objections to using URIs in prefixes and RDFa in general
his vote against it RDFa
sorry for not being able to stay around longer!
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/)./)?/ Succeeded: s/by doc/by doc only/ Succeeded: s/otw/otherwise/ Succeeded: s/get/gets/ No ScribeNick specified. Guessing ScribeNick: harry Inferring Scribes: harry Default Present: jar, DBooth, hhalpin Present: jar DBooth hhalpin Got date from IRC log name: 12 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/12-awwsw-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]