W3C home > Mailing lists > Public > public-awwsw@w3.org > February 2011

Re: Proposal, a new class of Web Names

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 15 Feb 2011 09:01:55 -0500
Message-ID: <AANLkTi=3gn7-ooCgre+HBhZUAfZ+S3c28Maq5oDdjgNu@mail.gmail.com>
To: Michael Hausenblas <michael.hausenblas@deri.org>
Cc: Nathan <nathan@webr3.org>, AWWSW TF <public-awwsw@w3.org>, Tim Berners-Lee <timbl@w3.org>
Well well well, small world.  I was assigned to track this question
for the TAG.  I was in correspondence with Ben and Manu and didn't
know you were looking at this too.


I've linked my action to your writeup and to RDFa issue 84, so maybe
we'll be able to knit this together.

Since 3986 is authoritative for fragid semantics I'd be sure to use
that as a starting point in any spec-conscious writeup - I was
surprised you don't even refer to it on that page. You could say that
you choose to ignore what it says, since it's borderline nonsense, and
that you use the (nonauthoritative) AWWW interpretation instead (which
is also borderline nonsense, but nonsense that's more useful for RDF
purposes). That's similar to what I asked Manu to do. Here inside W3C
you've got to either follow the RFCs, change them, or own up publicly
to the fact that you're at variance. I suspect AWWW is not quite as
direct about this as it ought to be.

If you wanted to fix the problem, or at least part of it, note that
the +xml and html media type registrations are both in the process of
being revised. The new +xml makes things considerably worse for RDFa.


On Tue, Feb 15, 2011 at 8:39 AM, Michael Hausenblas
<michael.hausenblas@deri.org> wrote:
>> I came up with the following yesterday in conversation with Manu
>> concerning use of # in RDFa: {Don't write <div id="foo" about="#foo">
>> if you're at all concerned that the element [see media type reg.] and
>> the thing you're calling #foo might have different properties - use
>> different fragids in that case.}
> My 2c - that's why I wrote up [1] (with support of Nathan migrated to the
> new location ;)
> Cheers,
>      Michael
> [1] http://www.w3.org/2001/sw/wiki/RDFa/FragmentIdentifiers
> --
> Dr. Michael Hausenblas, Research Fellow
> LiDRC - Linked Data Research Centre
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel. +353 91 495730
> http://linkeddata.deri.ie/
> http://sw-app.org/about.html
>> From: Jonathan Rees <jar@creativecommons.org>
>> Date: Tue, 15 Feb 2011 08:31:05 -0500
>> To: Nathan <nathan@webr3.org>
>> Cc: AWWSW TF <public-awwsw@w3.org>, Tim Berners-Lee <timbl@w3.org>
>> Subject: Re: Proposal, a new class of Web Names
>> Resent-From: AWWSW TF <public-awwsw@w3.org>
>> Resent-Date: Tue, 15 Feb 2011 13:32:40 +0000
>> Let me see if I've got this:
>> The problem (in my restatement of what you said) is that different
>> people want to use dereferenceable URIs in different ways. In
>> interoperability scenarios they would be seen to be fighting over
>> ownership of linguistic territory, and the poor agent stuck in the
>> middle attempting to combine artifacts from the two sides (e.g. using
>> owl:imports) is going to get wrong answers.
>> So the solution is to retract httpRange-14 (and all the other specs
>> that say the same thing) - http://example/x instead of always meaning
>> the document always means the same thing that http://example/x# does,
>> and that's defined... how? According to 3986 you look at the media
>> type and go from there, so for HTML and XML it would mean an element
>> (which could never be defined since the empty string is not a valid
>> element id), and for RDF would be as 'defined' by the RDF.
>> This is nice for those who don't like # because it gives them a way to
>> write a # URI without writing the # character, and they don't have to
>> bother with 303. In fact I don't see how it differs from what Ian and
>> Harry are saying at all. Those of us who have been using
>> dereferenceable URIs to refer to documents are left in the cold and
>> would have to make up a new notation (see my TAG slides).
>> To me it would seem easier just to keep with httpRange-14 and say that
>> dereferenceable LOD URIs actually do refer to documents - specifically
>> nodes in the LOD network. The L in LOD  would be a
>> document-to-document relation which is what I think that community
>> wants. Maybe we say it privately among ourselves, but at least we
>> would have a consistent way to interpret combined OWL/LOD graphs.
>> I came up with the following yesterday in conversation with Manu
>> concerning use of # in RDFa: {Don't write <div id="foo" about="#foo">
>> if you're at all concerned that the element [see media type reg.] and
>> the thing you're calling #foo might have different properties - use
>> different fragids in that case.} If you don't care about inference
>> (your own or anyone else's) then of course it doesn't matter which you
>> do, so you're happy. If you do, you use different fragids and again
>> you're happy. Maybe the same approach would work with dereferenceable
>> URIs.
>> (1/2 cynical here, but want to explore options.)
>> Jonathan
>> On Mon, Feb 14, 2011 at 6:15 PM, Nathan <nathan@webr3.org> wrote:
>>> Hi Guys,
>>> Please do read over the following and let me know what you think - might be
>>> somewhat of a different approach ->
>>> [[[
>>> Problem Statement and Background.
>>> The Web has long since provided names as a way of referring to things, from
>>> time to time the specification of these names has had to be revised, in
>>> order to match their usage on the Web as it evolves.
>>> With the rise of the Semantic Web, Media Fragments and Web Applications, the
>>> usage of these names, especially http names, has changed to become either
>>> inconsistent with the current URI specification or their usage is simply
>>> unspecified.
>>> A side effect of this new usage, is that various communities have differing
>>> opinions on just what a URI can or does refer to, and on how those URIs can
>>> be used. This leads to tensions between communities which are trying to
>>> converge, and in the worst case threatens the evolution of those communities
>>> and their respective technologies.
>>> The web communities using these URIs share two common requirements, they
>>> need to use absolute URIs to refer to network accessible resources, and they
>>> require some form of indirect referencing, frequently turning to fragment
>>> identifiers for this purpose.
>>> One of the most contended uses of URIs, is when they are used to refer to
>>> abstract concepts or things evoked by the processing of representations, for
>>> example:
>>>  - A thing which is described within a representation, i.e. a person.
>>>  - A particular application state or recomposable view provided by the
>>> application.
>>>  - Some particular scene within a movie.
>>> Contentions are usually particularly high when a URI of the absolute-URI
>>> form is used for this purpose.
>>> In order to address this problem, it is suggested that a new class of Web
>>> Names is needed. A class which is disjoint with the current set of names
>>> (URIs/IRIs), fully compatible with those names, and which models existing
>>> naming conventions.
>>> Proposal - Web Names.
>>> Web Names provide a web friendly way of referring to things, each WebName is
>>> a 2-tuple comprising of a namespace and a name.
>>>  WebName  = ( namespace , name )
>>> The namespace part of a WebName takes the syntactic form of an absolute-IRI,
>>> the namespace typically refers to a network accessible resource.
>>> Each namespace has an infinite pool of locally scoped references, within
>>> different contexts there often exists a need to expose one of those
>>> references, for example:
>>>  - a reference to something which is described
>>>  - a reference to a particular state or information view
>>>  - a reference to a function or a variable
>>>  - a reference to a particular time sequence and area within a video
>>> The name part of a WebName provides a way to expose these indirect
>>> references, the name can take the syntactic form of the primary-ref (an
>>> empty string) or a reference (a string consisting of one or more
>>> characters), the name provides an anchor to refer to things named within a
>>> namespace.
>>> WebNames have the following syntax:
>>>  web-name     =  namespace local-name
>>>  namespace    =  absolute-IRI
>>>  local-name   =  [ "#" ] primary-ref / "#" reference
>>>  primary-ref  =  0<ipchar>
>>>  reference    =  1*( ipchar / "/" / "?" )
>>> Since WebNames are 2-tuples and IRIs are strings, the value space of
>>> WebNames is completely disjoint with the value space of IRIs, however, the
>>> lexical form of each WebName is also a valid IRI, as such:
>>>  IRI          =  http://example.com/foo/bar#baz1
>>>                  \________________________/ \__/
>>>                                  |           /
>>>  WebName      =             ( namespace , name )
>>> By sharing a lexical form which always produces a valid IRI, WebNames are
>>> fully compatible with the deployed web technologies, require no changes to
>>> be made, and are backwards compatible with existing IRIs which have been
>>> minted/used for the purpose of indirect referencing.
>>> Due to WebNames being 2-tuples, they cannot be dereferenced, this serves to
>>> null and void many of the most complicated and contentious issues outlined
>>> earlier, WebNames have been designed in such a way so that communities can
>>> opt-in to using them and focus on converging their technologies rather than
>>> trying to answer unanswerable questions.
>>> It is often the case that a network accessible resource is configured to
>>> provide information primarily about a single thing, for this purpose a
>>> WebName consisting of a namespace and a primary-ref can be used.
>>> When the name part of a WebName is the primary-ref, then the hash ("#") is
>>> optional, such that the WebName:
>>>  ( "http://example.com/foo/bar" , "" )
>>> can be specified using either of the following lexical forms:
>>>  http://example.com/foo/bar#
>>>  http://example.com/foo/bar
>>> and such that both those lexical forms encode the same WebName.
>>> ]]]
>>> Still needs work, especially on the text, but I think that's enough to get
>>> across what I'm proposing in the meantime. Thoughts and feedback more than
>>> appreciated.
>>> Best,
>>> Nathan
Received on Tuesday, 15 February 2011 14:02:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC