- From: Phil Archer <phila@w3.org>
- Date: Wed, 19 Aug 2015 17:16:34 +0100
- To: Makx Dekkers <mail@makxdekkers.com>, public-dwbp-wg@w3.org
The devil is in the detail of the HTTP interaction. You give your user agent the full URI http://philarcher.org/foaf.rdf#me. It then strips off the fragment, because fragments are not transmitted over the wire, and does a GET on http://philarcher.org/foaf.rdf. The server responds with 200 OK, here's what you asked for. The user agent then looks inside the document received for something matching the fragment identifier it stripped off earlier. How this is done is dependent on the user agent and the particular media type. In this case, an RDF-aware UA now looks for any triples in which http://philarcher.org/foaf.rdf#me is the subject. There it finds that the thing identified by http://philarcher.org/foaf.rdf#me has foaf:name Phil Archer foaf:nick PhilA etc. Those triples describe the thing identified by http://philarcher.org/foaf.rdf#me, not the thing identified simply by http://philarcher.org/foaf.rdf Does that clarify the situation? Phil. On 19/08/2015 17:02, Makx Dekkers wrote: > Phil, > > You told me recently about the hash-URIs as identifiers for real-world > objects and I liked the approach, but I am not sure if I understand your > reasoning here. > > I understand that you want to use http://philarcher.org/foaf.rdf#me to > identify you as a person. > > That is fine, but it is what you *want* it to mean. If I don't know your > intention, the only thing I see is a URL, namely the locator for a piece of > RDF in the file http://philarcher.org/foaf.rdf. What happens when I click on > 'your' URI is that I get back a file with some RDF and status code 200 > (success) which I think implies that I get back a (piece of a) document that > is located at the location #me in the file http://philarcher.org/foaf.rdf. > > So I do think http://philarcher.org/foaf.rdf#me is a URL to a piece of code > that describes you that you want to be used as an identifier for you as a > person. > > Makx. > > >> -----Original Message----- >> From: Phil Archer [mailto:phila@w3.org] >> Sent: 19 August 2015 16:30 >> To: Annette Greiner <amgreiner@lbl.gov>; Manuel.CARRASCO- >> BENITEZ@ec.europa.eu >> Cc: public-dwbp-wg@w3.org >> Subject: Re: Data Identification section (was Re: reviewing the BP doc) >> >> Sorry Annette, on this rare occasion I must disagree with you. >> >> http://philarcher.org/foaf.rdf#me is a URI. It is not a URL as it > identifies a >> resource, me, that, like any other physical object, or concept, cannot be >> obtained over the internet. I do not have a network location. >> >> http://philarcher.org/foaf.rdf is a URL, it identifies a resource that > does have >> a network location, i.e. it can be obtained directly over the internet. >> >> So there's a hierarchy here of URIs, HTTP URIs and URLs. >> >> As evidence, let me quote RFC 3986 (the definition of URIs, >> https://www.ietf.org/rfc/rfc3986.txt), section 1.1.3: >> >> >> 1.1.3. URI, URL, and URN >> >> A URI can be further classified as a locator, a name, or both. The >> term "Uniform Resource Locator" (URL) refers to the subset of URIs >> that, in addition to identifying a resource, provide a means of >> locating the resource by describing its primary access mechanism >> (e.g., its network "location"). >> >> RFC 3987 introduces the even more general IRI which allows Unicode >> characters outside the limited ASCII set. >> >> The WG has made it clear that it wants to avoid providing any discussion >> of the issue. That seems fine to me as it avoids unnecessary confusion, >> BUT, if we're not going to say something along the lines of "we know all >> these things are different but for simplicity we'll just use the one >> term" then we must use the correct term in the correct place. >> >> Last week we ended up voting on a proposed resolution: >> >> PROPOSED: In general URI should be used in the BP doc, but depending on >> the context, URL may also be used. >> >> This didn't meet with consensus - some people were unsure, Tomas was >> opposed. >> >> Looking at other W3C specs btw, we use IRI pretty much everywhere. See, >> for example, http://www.w3.org/TR/tabular-metadata/. >> >> So the hierarchy is: >> >> IRI >> URI >> HTTP URI >> URL >> >> Therefore, IMO, the correct course of action in this, a technical >> specification document, is to use the term IRI except where context >> dictates that another term be used. >> >> Phil. >> >> On 13/08/2015 19:54, Annette Greiner wrote: >>> For our document, URIs and URLs are the same thing, since we are not >> concerned with entities that don't have a location on the web. The >> document uses URI currently. I'm fine with keeping that or using URL > instead. >> Either way, my point is that we don't need to launch into a discussion of > the >> differences. I'm fine with a footnote referencing RFC 3986 if people feel > it's >> necessary. >>> -Annette >>> -- >>> Annette Greiner >>> NERSC Data and Analytics Services >>> Lawrence Berkeley National Laboratory >>> 510-495-2935 >>> >>> On Aug 13, 2015, at 2:02 AM, Manuel.CARRASCO-BENITEZ@ec.europa.eu >> wrote: >>> >>>> Annette, >>>> >>>> We should just use URL, the subset of URI with a network location >> mechanism. We *cannot* redefine term such URL and we must just point to >> the source specifications: we cannot break the existing specifications. >>>> >>>> I agree that the document is getting to long and hence the proposition > to >> separate the identification: it is easier to produce and consume. >>>> >>>> Regards >>>> Tomas >>>> >>>> >>>> From: Annette Greiner [amgreiner@lbl.gov] >>>> >>>> Sent: 12 August 2015 20:11 >>>> >>>> To: Phil Archer >>>> >>>> Cc: CARRASCO BENITEZ Manuel (DGT); public-dwbp-wg@w3.org >>>> >>>> Subject: Re: Data Identification section (was Re: reviewing the BP doc) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Aug 12, 2015, at 7:56 AM, Phil Archer <phila@w3.org> wrote: >>>> >>>> >>>> >>>> >>>> >>>> * ?R? >>>> >>>> URI, URL, URN, IRI. Just use URI everywhere and add something like: >>>> >>>> >>>> >>>> "In this specification, the term URI is used for the identification > schemes: >> URI, URL, URN and IRI ..." >>>> >>>> >>>> >>>> This is line with the recommendation in RFC3986 >>>> >>>> https://tools.ietf.org/html/rfc3986#section-1.1.3 >>>> >>>> >>>> >>>> " ... Future specifications and related documentation should use the >> general term "URI" rather than the more restrictive terms "URL" and >> "URN" ..." >>>> >>>> >>>> >>>> But >>>> we *want* to be restrictive. We're only talking about HTTP URIs, we're >> not talking about URNs, or even URLs. Hence I think we need to say >> something, no? >>>> >>>> >>>> >>>> >>>> Funny, I take the fact that we want to be restricted to discussing URIs > as a >> reason *not* to add a discussion about them vs. URNs or URLs. The fact > that >> we use a term in our document doesn't mean that we have to define it. It > is >> defined elsewhere in W3C >>>> space plenty. Our document is already annoyingly long; let's help > readers >> get to what is helpful information and leave out discussion that is not > unique >> to publishing data on the web. >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Annette Greiner >>>> >>>> NERSC Data and Analytics Services >>>> >>>> Lawrence Berkeley National Laboratory >>>> >>>> 510-495-2935 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> >> >> Phil Archer >> W3C Data Activity Lead >> http://www.w3.org/2013/data/ >> >> http://philarcher.org >> +44 (0)7887 767755 >> @philarcher1 > > > -- Phil Archer W3C Data Activity Lead http://www.w3.org/2013/data/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Wednesday, 19 August 2015 16:16:50 UTC