Re: [ALL] proposed resolution httpRange-14

* Ralph R. Swick <swick@w3.org> [2005-03-23 14:00-0500]
> 
> At 06:11 PM 3/17/2005 +0000, Jeremy Carroll wrote:
> >I propose that
> >
> >an http URI without a hash MAY be used to identify an RDF property
> ...
> >Our primary concern is:
> >    - deployed semantic web applications such as Dublin Core [1],
> >Friend-of-a-friend [2], Creative Commons [3], Adobe XMP [4], RSS 1.0 [5]
> >that use such URIs

One observation here: if DC, FOAF, CC, XMP, RSS1 etc are in error, and 
deploying in a manner inconsistent with the Architecture of the Web, 
we should be careful not to use "well, we shipped already..." as an
argument. I don't believe the use of # in property names is a violation
of Web architecture, though am prepared to be persuaded otherwise. If 
it is, the existing deployment of DC/FOAF/CC/XMP/RSS1 is a major problem and we 
will need to seek support, advice and guidance from TAG, the W3C 
Communications Team, and W3C Members in determining a migration path and 
strategy for rescuing the situation. So I'm looking to the TAG really to 
(i) appreciate the seriousness of the situation (ii) work with us on 
finding a reading of WebArch, the URI and HTTP specifications which 
is grounded in published specs rather than opinion, which does no harm, and 
which (for pragmatic reasons) avoids creating huge disruption. I am 
optimistic that this can be achieved, because I believe there is a story 
for treating properties (and classes etc) as humanly created artifacts just 
like Web pages, and hence as entitled to be named with HTTP names as
other Web-representable Works. I do fear that we will have an
unproductive interaction with TAG if we take a line that could be seen 
as bullying based on 'facts on the ground' rather than on the
appropriate specifications.


> >Other important concerns are:
> >    - the practical difficulty of using '#' namespace URIs for large
> >vocabularies such as wordnet
> >    - the impossibility of doing server side redirects on '#' URIs
> 
> We might quibble over whether there is a "primary" concern and
> two "secondary" ones or whether each is primary to some
> constituency.  We heard input at the Boston meeting that each
> of these three was key to someone.
> 
> I suggest rewording as "Our primary concerns are:" and not
> separating two subclasses.  I further suggest generalizing
> "server side redirects on '#'" to "server side processing of
> the fragment identifier component" (that is the language of
> RFC 3986).

+1 

I consider these secondary concerns. 

> Otherwise, I have no trouble with the tone of this draft (or perhaps
> have simply gotten comfortable with it.)  I think the TAG will understand
> that we are prompted to send this resolution by a consensus that leaving
> it as an open issue is as much or more harmful to our deployment efforts
> as are some of the possible TAG findings on the issue.

My concern re tone is described above. While I am certain that W3C
pushing the 'no #' line would be ignored in the marketplace, and a 
potential disaster for SW deployment, I'd rather emphasise the 
possibility for a low-meladrama hybrid position, ie. that properties and 
classes are human 'works' that are represented and named in the Web in
exactly the same way as digital images or HTML prose. Note that such a 
consensus would leave open some questions important to some SW
deployers (Patrick Stickler I think) as well as (I believe) the Topic
Maps community, since it doesn't force the issue of whether cars,
people, planes, and other physical entities can also be named with
#-free HTTP URIs. But it would save a major disruption to some very 
widely used namespaces, which I think is an important first step to 
defusing the situation. 

Dan

ps. I should also reiterate that I am prepared to migrate FOAF to a
#-based namespace URI, on two preconditions (i) TAG and SWBPD WGs agree
that #-free HTTP URIs for properties and classes violate Web
Architecture (WebArch spec, URI spec, HTTP spec) (ii) we have a SW
Coordination Group and W3C Comm-team blessed outreach plan for 
sending a consistent (and positive) message to RDF users,
implementors, and other "/"-based namespace owners, so that I can explain 
the reason for this change to FOAF adopters and have some hope that FOAF
files will also be freed of other "/"-based namespace URIs. Ideally we
would do this at the same time for the other key namespaces commonly 
found in documents, application code, XSLTs, queries etc alongside FOAF, 
since people are unlikely to have to change their work on multiple 
occasions. That said, I'm still prepared to go first with FOAF if the WG
think that is in the best interests of SW deployment.

Received on Wednesday, 23 March 2005 19:40:26 UTC