RE: [VM] Skip Oct 11 telecon? (next Oct 25)?

OK by me.

> -----Original Message-----
> From: public-swbp-wg-request@w3.org
> [mailto:public-swbp-wg-request@w3.org]On Behalf Of Thomas Baker
> Sent: 10 October 2005 14:55
> To: SW Best Practices
> Subject: [VM] Skip Oct 11 telecon? (next Oct 25)?
> 
> 
> 
> Dear all,
> 
> The 27 Sep telecon is reported at
> http://www.w3.org/2005/09/27-vmtf-minutes.html (and in clear
> text below).  There were two main actions:
> 
>     1) Danbri to write up how foaf URI dereferencing
>        works now and how it should be done.
> 
>     2) Tom - same for DCMI.
> 
> I have been liaising with DCMI colleagues on this and have
> nothing to report back yet but do expect to have this before
> Oct 25.  Dan?
> 
> I would prefer to skip tomorrow's scheduled telecon and aim
> at the next, on Tuesday, October 25 (1300 UTC/1500 Amsterdam).
> 
> If others have progress to report and would prefer to keep to
> the scheduled time, I could arrange to do this though, in that
> case, I would prefer to keep the meeting to under 50 minutes.
> 
> What do others prefer?
> 
> Tom
> 
> ----
> 
> SWBPD VM Task Force 
> 
> 27 Sep 2005 Telecon 
> 
> Agenda: 
> http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0111.html 
> 
> IRC log: IRC http://www.w3.org/2005/09/27-vmtf-irc 
> 
> Previous telecon: 2005-07-19
> http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jul/0064.html
> 
> Attendees 
> 
>     Chair 
>         Tom Baker 
>     Scribe 
>         Alistair Miles 
>     Present 
>         Dan Brickley 
>         Ralph Swick 
>         Bernard Vatant 
> 
> Summary of Action Items 
> 
> [NEW] ACTION: danbri to write up how foaf URI dereferencing
> works now, and how it should be done. [recorded in
> http://www.w3.org/2005/09/27-vmtf-minutes.html#action01]
> 
> [NEW] ACTION: tom to write up current DCMI URI dereferencing
> works now, and how it should be done. [recorded in
> http://www.w3.org/2005/09/27-vmtf-minutes.html#action02]
> 
> 
> 
> In preparation for today's telecon, Alistair described how 
> SKOS currently
> handles dereferencing URIs and proposed some changes to the current
> policy.
> 
> RalphS My response to Alistair's thoughts didn't make 
> complete sense as
> I momentarily forgot that SKOS URIs use '#'.
> 
> Tom: Here's the problem: if you click on
> http://purl.org/dc/elements/1.1/title in your browser, you get a
> screenful of angle brackets -- the top of the RDF schema. So 
> far, we have
> assumed this is reasonable practice, but in Madrid, we agreed 
> this is no
> longer good enough in 2005... The options are: 1) some sort of content
> negotiation, or 2) a Web page that somehow points or 
> redirects to the RDF
> schema (e.g. via the link attribute). The idea is that by 
> default, users
> are shown a readable Web page, and applications which want to consume
> RDF can do so.  In Madrid, no definite conclusion on best way forward.
> 
> Ralph: Important to use solution that respects compatibility with
> current tools, which expect to do a GET on property URIs and expect
> RDF/XML content. So if we require they do accept 
> application/rdf+xml it
> is probably okay.
> 
> Alistair: What I proposed regarding SKOS Core tries to do 
> both of these
> things: requesting text/html returns a human-readable document. This
> is different from what DCMI currently does. If the clients asks for
> RDF/XML it gets redirected to something that is RDF/XML. This feature
> of DCMI -- using redirects -- is a good idea. So I'm in favor of using
> content negotiation.
> 
> Tom: The content negotiation option seems clear; the other option
> fuzzy. Was it to have a Web page with an embedded pointer to the RDF
> schema, and if enough people did it then applications would have to
> handle it?
> 
> Danbri: Remember EricM saying something about linking to RDF.
> 
> RalphS: Published recommendation says something about link.
> 
> Danbri: Webarch provides for content negotiation -- see
> http://www.w3.org/TR/webarch/#def-coneg.
> 
> Tom: So do we have a consensus here for content-negotiation?
> 
> RalphS: Other option is embedded RDF (XHMTL 2.0)
> 
> Danbri: Previous FOAF specs have embedded RDF/XML at the expense of
> validation.
> 
> Ralph: Support as much RDF as we can as embedded, but not necessarily
> everything.  RDF/A syntax is what HTML TF is converging on, is it
> reasonable to express RDF schema as RDF/A? But RDF/A solution does not
> address deployed tools.
> 
> Tom: Does content negotiation raise issues with regard to 
> deployed tools?
> 
> RalphS: Yes, but cheap and tools should change to do this 
> anyway. Wanted
> to ask if embedded RDF was talked about in Madrid.
> 
> Danbri: I am trying to figure out what do do with FOAF
> namespace. Currently, it uses the wrong 30x redirect. 
> Currently, it goes
> from a term URI to the namespace URI -- e.g., Apache "RedirectTemp
> /foaf/0.1/Organization http://xmlns.com/foaf/0.1/" goes from
> http://xmlns.com/foaf/0.1/Organization to http://xmlns.com/foaf/0.1/.
> Can then get that with HTML or RDF. We have discussed doing 
> redirect so
> that e.g.  http://xmlsn.com/foaf/0.1/mbox redirects to 
> spec#term_mbox. But
> problem with hash and encoding in Apache with rewriting... Reasonable
> for clients to get redirects depending on content type requested.
> 
> RalphS [re Accept: application/rdf+xml] -- it's a shame it 
> took us several
> years to tell application developers what content type to 
> request, but oh
> well. But with the above options, redirects are 
> content-type-specific? How
> do you configure in Apache?
> 
> Danbri Current: RedirectTemp /foaf/0.1/Organization
> http://xmlns.com/foaf/0.1/.  Possible: RedirectTemp 
> /foaf/0.1/Organization
> http://xmlns.com/foaf/0.1/#term_Organization.  Problem 1: # 
> gets escaped
> somehow (reported by Al). Problem 2: This becomes 
> representation-specific:
> #term_Organization is an anchor only in the HTML version of 
> the namespace
> document; it means nothing in the RDF version.
> 
> RalphS It doesn't strike me that different redirects based on Accept:
> is architecturally bad, but if there's no apache support 
> that's an issue
> for us.
> 
> Alistair Current browsers preserve their fragID across redirects.
> 
> RalphS So a redirect that includes a fragID would lead to 
> fragID clashes?
> Suspect Alistair is right but wonder if it is actually 
> endorsed by HTTP
> spec. If it is not endorsed then not all browsers may do it.
> 
> Danbri Ah, so a link such as <a
> href="http://xmlns.com/foaf/0.1/Organization#term_Organization
> ">Organization</a>
> might redirect to right part of the HTML document.
> 
> RalphS Perhaps we could ask the TAG if it is legitimate for a 
> server to
> return a fragID in a redirect -- ask the TAG if it is legit 
> for a server
> to return a URI with a hash in a redirect?
> 
> Tom: Stepping back, we seem to have consensus on 
> content-negotiation on
> this call, so we could as a next step write up how this works, leading
> to issues with the TAG and compatibility with spec?
> 
> Alistair Apache URI-encodes '#' before serving a redirect to 
> the client
> but purl.org leaves '#' un-encoded.
> 
> Danbrieg <a
> href="http://xmlns.com/foaf/0.1/Organization#term_Organization
> ">Organization</a>
> took me to http://xmlns.com/foaf/0.1/#term_Organization. The option
> of "redirect with content negotiation", on a / namespace, means that
> term URIs can't redirect to parts of the HTML spec. Am 
> realising that /
> namespace URIs prevent us getting clickable term URIs for 
> correct sections
> of a document.
> 
> I also tested redirects with hash for FOAF --
> http://xmlns.com/foaf/0.1/Organization#xyz . So Apache hash encoding
> makes sense if browsers hang on to fragIDs across redirects.
> 
> RalphS: Above redirect is broken.
> 
> Danbri: Can document this as one of the tradeoffs for hash vs slash.
> 
> RalphS: Is there a document which describes FOAF URI resolution policy
> now, and what it should be in light of the Madrid discussion? Can
> you write this up?  Propose you write how it is now, then write best
> guess on how it should work -- along the lines of Alistair's SKOS Core
> resolution message.
> 
> <danbri>
> http://rdfweb.org/viewcvs/viewcvs.cgi/xmlns.com/htdocs/foaf/0.
> 1/.htaccess
> 
> <scribe> ACTION: danbri to write up how foaf URI dereferencing
> works now, and how it should be done. [recorded in
> http://www.w3.org/2005/09/27-vmtf-minutes.html#action01]
> 
> <scribe> ACTION: tom to write up current DCMI URI dereferencing
> works now, and how it should be done. [recorded in
> http://www.w3.org/2005/09/27-vmtf-minutes.html#action02]
> 
> Alistair We can state our [DCMI, SKOS, FOAF] requirements, 
> perhaps more
> simply than we can describe what currently is implemented.
> 
> Ralph: It's fine to use MUST and SHOULD in a requirements document.
> 
> Tom: MARC Relator codes are currently declared as RDF 
> properties. Clicking
> on a term [ http://www.loc.gov/loc.terms/relators/ILL
> currently gets you to a Web page (see also
> http://www.loc.gov/loc.terms/relators/dc-relators.html),
> but you have to know to go elsewhere for the RDF [
> http://www.loc.gov/loc.terms/relators/dc-relators.xml].  This is nice
> for humans, but not ideal for applications.
> 
> Bernard: In recently posting, ask about relationship to Published
> Subjects. If we go down this route of making URIs friendly to 
> both humans
> and computers they start to behave alot like publish subjects. Can we
> characterise the similarities and differences? When we did Published
> Subjects, recommendation for way that computers would use 
> annexed schemas
> was not clear. Published Subjects primarily directed at 
> humans. Now with
> this new state of things we could revisit pubsub.
> 
> RalphS: Useful line of investigation ... gives us way to do
> convergence. But one issue is if there is a disagreement between
> interpretation of human-readable and machine-readable, which do you
> believe?
> 
> Bernard: TMs have no notion of a contradiction, no notion of 
> consistency,
> just some binding points for bits of information about a subject. But
> no way to make sure these things are consistent -- which is 
> why AI folks
> don't like TMs. But consistency between human and computer 
> descriptions
> is difficult to control.
> 
> <danbri> "This specification does not attempt to enumerate all the
> possible forms of vocabulary description that are useful for 
> representing
> the meaning of RDF classes and properties. Instead, the RDF vocabulary
> description strategy is to acknowledge that there are many techniques
> through which the meaning of classes and properties can be 
> described. ..."
> 
> <danbri> rdfs is (on purpose) agnostic re which forms of vocab desc
> take precedence
> 
> Tom: Longer-term, DCMI needs to re-examine the policy implications
> of declaring vocabularies by expressing the same information both
> in a Web document and in an RDF schema -- when does DCMI want to say
> which resource is 'authoritative'?  Providing parallel representations
> implicitly assumes that the representations are in sync. DCMI tries
> to ensure this by generating both forms of documentation from a single
> source. Currently, the Web pages present somewhat more 
> information (e.g.,
> historical versions of term descriptions) than the current RDF schema.
> The Web page [ http://dublincore.org/documents/dcmi-terms/] currently
> asserts itself to be an "authoritative specification"; the RDF schemas
> do not currently make the same assertion. Dublin Core started as an
> RFC [http://www.ietf.org/rfc/rfc2413.txt] and as Web documents, and
> this precedence of the Web document was never explicitly changed. This
> situation could change in the future, especially as DCMI moves towards
> saying more about the terms in a formal sense. DCMI would need to be
> explicit on authoritative nature of the representations.
> 
> RalphS: Is it a proper subset? Are there e.g. domains and 
> ranges in RDF
> overlooked in HTML?
> 
> Tom: DCMI terms are not currently defined with domains and ranges. A
> DCMI working group is currently looking at domains and ranges which
> might in principle be assigned to existing DCMI properties in order to
> reinforce semantics as they are currently interpreted. Such a step is
> seen as a positive step in principle, while recognizing the 
> danger that
> such additional assertions could in fact restrict semantics 
> as they are
> used in practice.
> 
> Danbri: One can say e.g. 'we believe these things are always in sync,
> if not tell us'
> 
> Bernard: Machine readable is normative, human readable is informative
> ... go in this direction?
> 
> Alistair "Which variant is authoritative" is a longer-term issue for
> SKOS too.  In SKOS, some constraints currently only described in prose
> and would be hard to express formally; perhaps by using 
> SPARQL. The RDF
> schema does not have enough information to specify all of the 
> constrains
> -- e.g., broader/narrower, and "there should be only one 
> preferred label
> per language".
> 
> DanBri: RDFS had a class ConstraintResource 
> [End of minutes]
> 
> First draft of minutes formatted by David Booth's scribe.perl 
> version 1.127 (CVS 
> log)
> $Date: 2005/09/27 14:00:42 $ 
> 
> -- 
> Dr. Thomas Baker                      baker@sub.uni-goettingen.de
> SUB - Goettingen State                            +49-551-39-3883
> and University Library                           +49-30-8109-9027
> Papendiek 14, 37073 Göttingen
> 
> 
>

Received on Monday, 10 October 2005 14:28:44 UTC