Current status: open
This is a FoafVocab issue, documented as such by linking it from the IssueTracker page.
FOAF currently names classes and properties with URIs such as: - http://xmlns.com/foaf/0.1/workplaceHomepage
An alternate design would be something like: - http://xmlns.com/foaf/0.1/#workplaceHomepage
Each FOAF term (ie. class, property) is a thing with an http:* URI as its name, without indirecting via the '#' fragment mechanism.
Context: the current FOAF design was itself motivated by concern about ns URIs that end in '#', since the denotation of URIs of the form http://example.com/something#somethingelse was complicated by mention of content negotation and context dependence in the URI spec (RFC2396).
Further discussion on what HTTP URIs name from TimBL in http://www.w3.org/DesignIssues/HTTP-URI
This issue tracker is for gathering evidence about the severity of the problem, if indeed it is a problem. Some claim that properties and 'http documents' are dijoint, ie. that nothing can be both an http document. FOAF can be seen as contradicting that.
Note also that FOAF's approach to this design choice is shared with the Wordnet vocabulary deployed at http://xmlns.com/wordnet/1.6/ (eg. classes such as http://xmlns.com/wordnet/1.6/Car), the Dublin Core vocabulary at http://purl.org/dc/elements/1.1/ (eg. properties such as http://purl.org/dc/elements/1.1/), as well as the preceding DC 1.0; also RSS 1.0 (http://purl.org/rss/1.0/ eg http://purl.org/rss/1.0/link) and some namespaces associated with Adobe's XMP system (deployed in Photoshop 7, PDF tools etc). Also Creative Commons rights metadata, see spec at http://www.creative-commons.org/metadata/spec using vocab named http://web.resource.org/cc/, classes with names like http://web.resource.org/cc/Work.
The W3C Technical Advisory Group(TAG) has an issue tracking a generalisation of this point: http://www.w3.org/2001/tag/ilist#httpRange-14 "What is the range of the HTTP dereference function?".
DC, RSS, Adobe XML, Creative Commons and FOAF when collected together account for a fair slice of all the RDF out there in the Web. If something's wrong, we will need some migration strategies that strike a balance between doing the right thing and preserving people's existing investment in these RDF apps.
I would also like more information about the class of things that can supposedly be named with HTTP names. What inferences can we draw when we see a URI that begins http: and doesn't contain a '#'? What things are true of all such resources?
- http-named things are not spatial things, they have no location in space and time - hmm, same goes for RDF classes and properties - ...
A HashURI is a URI with a hash mark ("#") in it (technically, a URI with a fragment identifier), specifically one used to denote something which is not a traditional web page.
Use of HashURIs is intended to help WhenBrowsableAndUnambiguousCollide. It is often presented in contrast to SlashURI, via the debate HashVsSlash.
The idea is to use URIs like
(document URI) # (term introduced in the document)
This works well for a lot of RDF content. It's very natural (especially with rdf:ID) to introduce a new conceptual thing and name it with the same action.
Web retrieval does approximately the right thing. When you ask for foo#bar, your client asks for a representation of foo and then (depending on the content-type of the result) may try to find something named bar in that result. (from HashURI on the ESW wiki)
When an issue is resolved or its status w.r.t. the FOAF spec changes, that changed state of affairs should be documented somewhere less transient than the wiki. See IssueTracker for more notes on issue management conventions.