IRC log of vmtf on 2005-10-28

Timestamps are in UTC.

11:47:26 [RRSAgent]

RRSAgent has joined #vmtf

11:47:26 [RRSAgent]

logging to http://www.w3.org/2005/10/28-vmtf-irc

11:47:32 [Zakim]

Zakim has joined #vmtf

11:47:41 [RalphS]

zakim, this will be vmtf

11:47:41 [Zakim]

I do not see a conference matching that name scheduled near this time, RalphS

11:47:52 [RalphS]

rrsagent, bye

11:47:52 [RRSAgent]

I see no action items

11:48:42 [RRSAgent]

RRSAgent has joined #vmtf

11:48:42 [RRSAgent]

logging to http://www.w3.org/2005/10/28-vmtf-irc

11:48:53 [RalphS]

rrsagent, please make logs public

12:07:53 [danbri]

danbri has joined #vmtf

13:00:35 [Zakim]

SW_BPD(VMTF)9:00AM has now started

13:00:44 [Zakim]

+Tom_Baker

13:01:00 [danbri]

hi folks

13:01:27 [Zakim]

+Danbri

13:03:36 [danbri2]

danbri2 has joined #vmtf

13:05:12 [Zakim]

+Ralph

13:05:26 [berva]

berva has joined #vmtf

13:06:04 [tomb]

tomb has joined #vmtf

13:06:09 [tomb]

hello?

13:06:11 [danbri]

hi

13:06:15 [berva]

hi folks - bernard here - coming on the phone

13:06:39 [RalphS]

RalphS has joined #vmtf

13:06:47 [RalphS]

zakim, who's on the call?

13:06:47 [Zakim]

On the phone I see Tom_Baker, Danbri, Ralph

13:06:56 [RalphS]

Regrets: Libby

13:07:09 [Zakim]

+??P30

13:07:19 [RalphS]

zakim, ??p30 is Bernard

13:07:19 [Zakim]

+Bernard; got it

13:08:16 [aliman]

aliman has joined #vmtf

13:09:20 [Zakim]

+??P0

13:09:30 [RalphS]

zakim, ??p0 is Alistair

13:09:30 [Zakim]

+Alistair; got it

13:09:45 [RalphS]

Agenda: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html

13:09:50 [danbri]

danbri has changed the topic to: SWBPD agenda: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html

13:09:54 [RalphS]

Meeting: SWBPD Vocab Management TF

13:09:57 [RalphS]

Chair: Tom

13:10:01 [danbri]

danbri has changed the topic to: SWBPD VMTF agenda: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html

13:10:36 [RalphS]

Previous: 2005-09-27 http://www.w3.org/2005/09/27-vmtf-minutes.html

13:10:43 [danbri]

q+ to ask whether Purl DC sending back a # is currently legal per HTTP, TAG etc

13:12:04 [RalphS]

DanBri: I wrote some thoughts in a blog post the other day

13:12:13 [RalphS]

[Ralph hopes for a pointer to that post]

13:12:28 [danbri]

http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0187.html

13:12:33 [danbri]

<- snapshot of blog post

13:12:48 [danbri]

(i s/\//#/ in the post subsequently)

13:14:40 [RalphS]

Scribe: Alistair

13:14:44 [danbri]

tx alistair

13:14:52 [RalphS]

ScribeNick: aliman_scribe

13:15:06 [aliman_scribe]

tom: marc relator terms resolve to a web page that just defines that one term ...

13:15:22 [aliman_scribe]

putting in content negotiation would also allow resolvoe to RDF ...

13:15:34 [danbri]

(that's an option i'd forgotten about)

13:15:41 [aliman_scribe]

but from user point of view quite nice, cos user gets just the bit they're looking for ...

13:15:55 [aliman_scribe]

attractive solution for users ...

13:16:34 [aliman_scribe]

danbri: forgotten that option, sounds attractive ...

13:16:52 [tomb]

http://www.loc.gov/loc.terms/relators/ILL

13:16:55 [aliman_scribe]

might vary depending on the namespace, might need to have links between pages ...

13:17:04 [aliman_scribe]

can see three designs ...

13:17:33 [RalphS]

Tom: http://www.loc.gov/loc.terms/relators/ILL returns just one term

13:17:44 [aliman_scribe]

tom: marc example, html generated from a database ...

13:17:56 [aliman_scribe]

from user pov its nice.

13:18:15 [aliman_scribe]

danbri: leaves lots of space on page for other stuff, e.g. status metadata

13:18:30 [danbri]

...and translations

13:18:37 [aliman_scribe]

tom: i like the principal that the URI for a term resolves to a human-readable depiction of that term ...

13:19:03 [aliman_scribe]

could add contextual info, versioning info ...

13:19:05 [RalphS]

[presuming content-negotiation also gives an application/rdf+xml depiction too]

13:19:15 [aliman_scribe]

can we agree on this as a guiding principal?

13:20:30 [RalphS]

Alistair: a single apache directive should be able to give an apache redirection match to the HTML

13:20:42 [RalphS]

... should be same as I'm using for SKOS except it uses a regex

13:21:08 [RalphS]

... asking for HTML causes a redirect, which uses part of the request URI in the redirected URI

13:21:22 [RalphS]

DanBri: does an RDF client always get one big document?

13:21:51 [RalphS]

Alistair: have options; can make a request for application/rdf+xml return anything we want independently of a request for text/html

13:22:15 [RalphS]

... the practicality of each option depends on how big the vocabulary itself is and some user considerations

13:22:33 [aliman_scribe]

tom: other option on html side is to have one big document and go to one part of that doc ...

13:22:38 [RalphS]

... except that for "/" namespaces you can't redirect to a specific point in a document

13:23:00 [RalphS]

... because of #-encoding

13:23:23 [RalphS]

DanBri: dublincore.org returns a redirect containing '#'

13:23:36 [RalphS]

... might not be possible with some apache versions

13:24:06 [RalphS]

Alistair: could lead to situations where client sees two fragments

13:24:26 [RalphS]

... I think we should accept the apache constraints and work around them

13:24:43 [RalphS]

... may need to have many small HTML documents and this would be the right solution

13:24:56 [danbri]

see http://chatlogs.planetrdf.com/swig/2005-10-25.html#T09-08-08 for log of what purl dc does

13:25:33 [RalphS]

Ralph: I see suggestions that loc.gov/loc.terms/ is using cocoon

13:26:01 [RalphS]

Tom: are we agreed that it is nice to resolve the URI of a term to that single term?

13:26:24 [RalphS]

... even if the server requires a single document per term?

13:26:27 [danbri]

purl dc behaviour above was http 1.0; here's the http 1.1 headers:

13:26:33 [danbri]

Server: Apache/1.3.27

13:26:35 [danbri]

Location: http://dublincore.org/2003/03/24/dces#title

13:26:36 [danbri]

Connection: close

13:26:38 [danbri]

Transfer-Encoding: chunked

13:26:39 [danbri]

Content-Type: text/html; charset=iso-8859-1

13:26:55 [danbri]

q?

13:27:00 [danbri]

q-

13:27:08 [RalphS]

Alistair: appears that LOC is using cocoon to either query a database or transform an XML document

13:27:34 [RalphS]

Tom: LOC does have RDF descriptions, they're just located at different URIs -- with .rdf appended

13:28:03 [RalphS]

Alistair: I expect most installations would manage the RDF form in an RDF service

13:28:19 [RalphS]

... could write a velocity servlet, for example

13:28:42 [RalphS]

... this would be a more advanced solution

13:28:59 [RalphS]

... small static pages would also work

13:29:22 [RalphS]

DanBri: use xslt?

13:29:44 [RalphS]

Alistair: yeah, could probably run an XSLT program over a SPARQL query result

13:30:37 [RalphS]

... I think it's fine for the URI of a term to resolve to a small bit of HTML describing only that term

13:30:43 [aliman_scribe]

bernard: how does the human user being redirected know that there are other representation?

13:31:12 [RalphS]

Bernard: how do you know what request the client is making?

13:31:27 [aliman_scribe]

... i.e. before making the request you don't know what representations are available ...

13:32:02 [aliman_scribe]

tom: good point. Could put in a cross reference from html page to rdf page as link ....

13:32:47 [aliman_scribe]

bernard: e.g. with SKOS example, you should be able to find out what representations are availabel before making a blind request.

13:33:16 [tomb]

q+ to ask whether there should be an overview of all representations somewhere

13:33:31 [aliman_scribe]

ralph: question is, given URI for a class or prop, do we want to serve multiple representations at that URI? ...

13:33:55 [aliman_scribe]

different from asking: if there are other representations, in what way should those other URIs cite the URI of the term ...

13:34:29 [aliman_scribe]

. Quite reasonable for an application to assume they can dereference URI of class or prop using preferred set of representatin types ...

13:34:46 [aliman_scribe]

i.e. you can ask for html first, rdf/xml second ...

13:35:05 [aliman_scribe]

so client doesn't need to guess what are available, it lists the things its willing to deal with in order ...

13:35:51 [aliman_scribe]

other linking is application specific, e.g. DC might have a seeAlso statement pointing to some other representation.

13:36:34 [aliman_scribe]

Bernard: Question is: is you have different aspects (representations) available for a resource, there is no way of knowing before hand which are available.

13:37:22 [aliman_scribe]

Ralph: Why does this matter? If you have a list of the representations you want to work with, you provide that list in order in the HTTP request. ...

13:37:58 [aliman_scribe]

If you get back something you didn't ask for, assume server doesn't have what you did ask for. What are circumstances where you need to know beforehand?

13:38:14 [aliman_scribe]

Tom: there should be an overview of all representations available for each term.

13:38:43 [aliman_scribe]

Bernard: yes, this description should be availabe, it's part of the description of the resource. ...

13:38:45 [aliman_scribe]

q+

13:39:29 [aliman_scribe]

bernard: ... user does not have access e.g. to the type-map file ...

13:39:56 [RalphS]

q+ to confirm that we agree that Best Practice is to serve an RDF representation at a minimum, so the question is whether we feel confident in recommending an [X]HTML representation _in addition_ as Best Practice

13:40:22 [RalphS]

Alistair: there might be some utility for functionality to learn the available representations ahead of time

13:40:32 [RalphS]

... I don't know of a way in HTTP to do this directly

13:40:40 [RalphS]

... but we can go a long way without having this functionality

13:40:49 [RalphS]

... I don't think we should worry about this just now

13:41:43 [RalphS]

DanBri: I don't think HTTP requires this, but the www.w3.org behavior is, e.g. in the case of the W3C icon, when you ask for a representation that doesn't exist you get back a page describing the available representations

13:41:52 [aliman_scribe]

danbri: w3c web server, e.g. w3c icon if you send HEADER for content-type it doesn't have, you get back message pointing to available types ...

13:42:05 [RalphS]

... so it's possible to configure web servers to give you an inspection ability

13:42:12 [Zakim]

tomb, you wanted to ask whether there should be an overview of all representations somewhere

13:42:19 [RalphS]

ack me

13:42:19 [Zakim]

RalphS, you wanted to confirm that we agree that Best Practice is to serve an RDF representation at a minimum, so the question is whether we feel confident in recommending an

13:42:23 [Zakim]

... [X]HTML representation _in addition_ as Best Practice

13:42:56 [aliman_scribe]

ralph: can we confirm that best practice that an RDF form be served at prop or class URI?

13:43:21 [aliman_scribe]

tom: I think so, this is in the requirements taht alistair posted attached to todays agenda.

13:43:56 [aliman_scribe]

ralph: given that this is the case, if our consensus is that you must serve some RDF at this URI, how strongly do we want to say e.g. you may serve an HTML representation ....

13:44:13 [aliman_scribe]

and we want to find a way to do that, that is consistent with webarch ....

13:44:28 [aliman_scribe]

and if we find a way that can reasonably be implemented by web servers ...

13:44:32 [tomb]

i agree

13:44:44 [aliman_scribe]

then we are likely to say best practice is to serve both RDF and HTML.

13:44:58 [tomb]

q+

13:45:04 [aliman_scribe]

... then it feels like Bernard's question goes away, because then client can assume that both RDF and HTML are avilable.

13:45:56 [aliman_scribe]

tom: How does a user know that other representations are available? It desirable that, for user at an html page, there should be links to or overview of other representations.

13:46:47 [aliman_scribe]

ralph: client can assume both are available. Are you saying, there may be a third type avilable ?

13:47:26 [aliman_scribe]

ralph: client should assume the rdf and html representaitons are available

13:47:29 [aliman_scribe]

q+

13:47:49 [aliman_scribe]

tom: client (user) should be aware of other variants

13:48:16 [RalphS]

s/(user)//

13:48:25 [RalphS]

oops

13:48:32 [RalphS]

Tom did say "user", not "client"

13:48:33 [aliman_scribe]

ralph: client should assume both are available, makes that information avilable to the user

13:49:08 [RalphS]

Tom: if a user is viewing a Web page, how does it know that there are RDF representations for the same things?

13:49:30 [RalphS]

Alistair: this issue is separate from Best Practices for dereferencing URIs

13:49:44 [RalphS]

... it is about best practices for documenting your vocabulary in HTML

13:50:27 [aliman_scribe]

bernard: point is similar to Tom's point, but agree not in focus for today, we're not speaking of different things.

13:50:35 [aliman_scribe]

tom: are you talking about user pov?

13:50:39 [aliman_scribe]

bernard; yes.

13:51:17 [aliman_scribe]

tom: we don't need to agree on that level of detail, because just getting the content negotiation issue solved is important ...

13:51:21 [RalphS]

q+ to ask if Bernard's "user" is the author of a Web page or the reader of that Web page

13:51:46 [aliman_scribe]

but users shouldn't click on URI for term and assume no RDF is available because they can't see it ...

13:52:51 [RalphS]

ah, perhaps the usability question involves a browser issue -- e.g. if users had some interface to easily tell their browser what representation to prefer on a given 'click'

13:53:27 [aliman_scribe]

q+

13:56:21 [RalphS]

ACTION: Tom produce a small draft of the consensus we've reached, starting with the text at the bottom of the agenda in http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html

13:57:16 [RalphS]

ack ali

13:57:33 [RalphS]

Alistair: I wrote a proposed dereferencing configuration for SKOS

13:57:38 [RalphS]

... I'd like to actually try this out

13:57:51 [RalphS]

... would like some discussion before I try this

13:59:34 [RalphS]

Ralph: I could probably persuade the W3C Webmaster and some other Team apache geeks to join us in telecon

14:00:11 [RalphS]

Alistair: I want to know both from an architectural point of view and an implementation point of view whether what I'm proposing is acceptable

14:02:39 [RalphS]

proposed next telecon Tuesday 15 Nov at 1400 UTC

14:03:21 [RalphS]

ACTION: Ralph to invite Matthieu, Gerald, Vivien, Ted to 15 Nov telecon

14:03:44 [RalphS]

ACTION: Alistair to write agenda for 15 Nov

14:04:12 [RalphS]

next telecon 15 Nov

14:04:37 [RalphS]

rrsagent, please draft minutes

14:04:38 [RRSAgent]

I have made the request to generate http://www.w3.org/2005/10/28-vmtf-minutes.html RalphS

14:04:59 [RalphS]

[adjourned]

14:05:01 [Zakim]

-Tom_Baker

14:05:04 [Zakim]

-Alistair

14:05:07 [Zakim]

-Bernard

14:05:08 [Zakim]

-Ralph

14:05:12 [Zakim]

-Danbri

14:05:15 [Zakim]

SW_BPD(VMTF)9:00AM has ended

14:05:16 [Zakim]

Attendees were Tom_Baker, Danbri, Ralph, Bernard, Alistair

14:05:21 [RalphS]

rrsagent, please draft minutes

14:05:22 [RRSAgent]

I have made the request to generate http://www.w3.org/2005/10/28-vmtf-minutes.html RalphS

14:05:34 [berva]

berva has left #vmtf

14:06:00 [RalphS]

zakim, bye

14:06:00 [Zakim]

Zakim has left #vmtf

14:06:34 [RalphS]

rrsagent, bye

14:06:34 [RRSAgent]

I see 3 open action items saved in http://www.w3.org/2005/10/28-vmtf-actions.rdf :

14:06:34 [RRSAgent]

ACTION: Tom produce a small draft of the consensus we've reached, starting with the text at the bottom of the agenda in http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html [1]

14:06:34 [RRSAgent]

recorded in http://www.w3.org/2005/10/28-vmtf-irc#T13-56-21

14:06:34 [RRSAgent]

ACTION: Ralph to invite Matthieu, Gerald, Vivien, Ted to 15 Nov telecon [2]

14:06:34 [RRSAgent]

recorded in http://www.w3.org/2005/10/28-vmtf-irc#T14-03-21

14:06:34 [RRSAgent]

ACTION: Alistair to write agenda for 15 Nov [3]

14:06:34 [RRSAgent]

recorded in http://www.w3.org/2005/10/28-vmtf-irc#T14-03-44