Re: Towards a consistent naming of W3C subdirectories

2009/7/1 Ian Jacobs <ij@w3.org>:
>
> On 1 Jul 2009, at 3:50 PM, Giovanni Campagna wrote:
>
>> 2009/7/1 Ian Jacobs <ij@w3.org>:
>>>
>>> On 1 Jul 2009, at 2:56 PM, Giovanni Campagna wrote:
>>>
>>>> 2009/7/1 Ian Jacobs <ij@w3.org>:
>>>>>
>>>>> On 1 Jul 2009, at 12:53 PM, Giovanni Campagna wrote:
>>>>>
>>>>>> I've been following the work on the new version of the W3C site for a
>>>>>> while, and I noticed that almost all the WG home pages, as well as
>>>>>> other pages with dated URIs or other weirdness are not currently
>>>>>> working.
>>>>>> I expected that being caused by the refactoring and resulting into new
>>>>>> sensible path component. I sent this email to make sure this happens.
>>>>>>
>>>>>> As an example, now we have /Style/CSS for CSS WG, but /html/wg for
>>>>>> HTML WG and /2001/tag for the TAG or /2001/sw for the Semantic Web
>>>>>> Activity.
>>>>>>
>>>>>> I think there are three models to solve this:
>>>>>> 1- /WG/CSS, /TAG, /activities/SemanticWeb, /IG/Math, /XG/ModelBasedUI
>>>>>> I.e., one (virtual) directory for kind of group, followed by the group
>>>>>> name
>>>>>>
>>>>>> 2- /Style/CSS, /TAG, /SemanticWeb/SWDeployment, /Markup/HTML,
>>>>>> /RWC/WebApps, /Incubator/ModelBasedUI
>>>>>> I.e. one (virtual) directory for Activity, followed by the group name
>>>>>>
>>>>>> 3- /1996/CSS, /2001/TAG, /2001/SemanticWeb, /2007/HTML, /2008/WebApps,
>>>>>> /2008/ModelBasedUI, /2007/XHTML2
>>>>>> I.e. the group name, associated with the year of start
>>>>>>
>>>>>> All group names should be consistenly CamelCased if possible (but I
>>>>>> know that W3C servers are case-instensitive)
>>>>>>
>>>>>> Of the three possibility, I personally favor number one, because
>>>>>> dropping the short name could bring to the list of currently active
>>>>>> working groups (one of the most difficult pages to reach, probably,
>>>>>> together with the list of TR ordered by working group).
>>>>>> Dropping the short name from 2 could give directly the activity page,
>>>>>> but I suppose that every WG will keep a link to its Activity (and
>>>>>> every Activity to its Domain), and people often want to group by
>>>>>> technology, rather than by activity.
>>>>>> Option n°3 is the one I dislike most, because currently
>>>>>> http://www.w3.org/XXXX is member / team only and thus completely
>>>>>> useless.
>>>>>>
>>>>>> I know that the W3C has URI persistence policies, but you can still
>>>>>> keep the old link and set a 301 Moved Permantly redirect to the new
>>>>>> location. Also, most URIs are not covered by those policies.
>>>>>
>>>>>
>>>>> Hi Giovanni,
>>>>>
>>>>> While consistent URIs are nice, they should not be required. People
>>>>> should reach pages through search engines or by following links, not
>>>>> by having remember URIs.
>>>>>
>>>>> I hope that the new site makes it easier to find information, without
>>>>> needing
>>>>> to worry about URIs.
>>>>>
>>>>>  _ Ian
>>>>
>>>> Most of time you need the same pages time over time, for example you
>>>> just need to check some WG's tracker or someother WG's blog.
>>>> In that case, you either use bookmarks, which may become too crowded
>>>> if you have to mantain a lot of addresses, or you manually type the
>>>> address.
>>>
>>> You shouldn't have to type addresses.
>>
>> Why shouldn't you?
>
> I think there are times you need to type or write URIs. But I have always
> understood that to be a suboptimal way of getting to a page that the URI
> refers to.
>
>> Or actually, why do we have addresses at all, if you don't have to
>> type them? Why not just UUID?
>
> We have addresses because they help with direct access. That doesn't mean
> that we should make people type them more than necessary.
>
> As I said, short, consistent URIs are a benefit. Changing our widely
> deployed
> URIs has a cost that we are unlikely to undertake. Instead we are making it
> easier to find the information.

Well, some URIs are deployed, like Technical Reports. I'm not asking
to change them (also there is no need to change them, /TR/some-spec is
simple and effective).
Some others instead, in particular referring to parts of the WG home
pages or pages in the member only site (online surveys, patent pages,
database of working groups) are not so widespread probably.

>>
>>>> Normally, you just type few characters and the browser
>>>> automatically finds the complete URI from the history.
>>>> I personally type addresses everytime I need something at the
>>>> www.w3.org.
>>>
>>> I'm sorry to hear that. I hope the new site makes it possible for you to
>>> avoid
>>> typing URIs.
>>
>> You cannot do anything to that, because I access pages without
>> starting from the main page and following links. I just want to go
>> straight to specific resources, and the easiest way is to type the
>> address.
>
> You should be able to type "html" in a search box (or in your URI box)
> and get to the page without typing (or knowing) the whole URI.

You can, but you must find useful keywords ("html" is not enough, you
need "html spec" or "html 4" or "html rec"), wait for Google to load
with the answer, skim the results...
For what concerns URIs stored in the history, sometimes it works (like
with list archives), sometimes it doesn't, it depends on the browser
and on your recent activity.

>>
>>>
>>>>
>>>> In addition, you need to type URIs if you write them on emails,
>>>> twitters, et similia. It is easier to remember
>>>> <http://www.w3.org/Join/AsInvitedExpert> than
>>>> <http://www.w3.org/2002/09/wbs/1/ieapp/>, and sure you don't want to
>>>> say to your colleague "goto to w3c home page, type 'invited expert
>>>> application' in the search field and hope for the better"
>>>>
>>>> That was from an usability point of view. The other point is that it
>>>> looks better.
>>>
>>> Agreed that shorter is better. :)
>>
>> Happy to see we agree on this.
>
> I appreciate the discussion and think we agree on more than this, but I am
> concerned about:
>
>  * Minting redundant URIs and the cost of having them (see the TAG's
> Architecture
>   document on multiple published URIs for the same thing)

For what concerns the abstract problem, your not publishing multiple
URIs for the same thing, you're publishing an URI representing the
former resource, and an URI representing the new resource.
For what concerns practical maintenance problem, I'm not sure. It may
just be for a limited time, before shutting down old URIs.

>  * The cost of getting consensus about URI syntax (a project I have no
> interest in undertaking)
>  * That we can achieve the goal of making it easy to get to information
> without focusing on the URI
>   syntax.

I depends on where you start looking from the information.

> If we were starting from scratch, we might do a better job as simpler,
> shorter URIs, but we're carrying
> a lot of URI baggage at this point. :)

Progressively creating new URIs following a standard pattern would
still be useful.

Giovanni

Received on Wednesday, 1 July 2009 21:24:20 UTC