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

Re: Proposal, a new class of Web Names

From: Michael Hausenblas <michael.hausenblas@deri.org>
Date: Tue, 15 Feb 2011 13:39:11 +0000
To: Jonathan Rees <jar@creativecommons.org>, Nathan <nathan@webr3.org>
CC: AWWSW TF <public-awwsw@w3.org>, Tim Berners-Lee <timbl@w3.org>
Message-ID: <C980327F.1AED3%michael.hausenblas@deri.org>
> 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 ;)


[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

> 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 13:39:47 UTC

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