[foaf-dev] Proposal: deprecate pastProject and currentProject
danbri at danbri.org
Mon Dec 14 13:32:49 CET 2009
On Mon, Dec 14, 2009 at 1:12 PM, Steve Harris <steve.harris at garlik.com> wrote:
> On 14 Dec 2009, at 11:55, Dan Brickley wrote:
>> (i forgot a bit)
>>> http://foo.example.org/#! could be a common prefix and
>>> http://foo.example.org/#!! a convention for 'the thing described by
>>> this document'. It doesn't seem used at the moment for anything else.
>>> I'm a bit worried we'll end up doubling the number of links, since
>>> whenever we mention some other document in an HTML hyperlink, we'll
>>> have to mention the thing it is about as well.
>> So, thinking was that in RDFa talking about me, I can have:
>> 2a. I spent much of the '80s at <a rel="foaf:schoolHomepage"
>> href="http://www.westergate.w-sussex.sch.uk/">Westergate School</a>.
>> "I spent much of the '80s at <a rel="foaf:school"
>> (this construct meaning: "at the school that is the main topic
>> described in the page at...")
> The bangbang thing seems a bit too much like line noise. what other
> suffices can you imagine that people might want after a bang?
The #! mini-ns has much the same use cases as rdf:ID in RDF/XML. So
local names for things being described. But naming the main topic of
the page is the most plausible reason to do this.
And yes, it is noisy, but so are fragile nests of spans and subtle
rules about when to use the URI for the thing, versus for the
page-about-the-thing, and when to include both URIs or to pick which
of the two is appropriate.
>> If we introduce a "hashbangbang" convention that uri#!! is owl:sameAs
>> tdb:uri, and that it names the thing that is the foaf:primaryTopic of
>> the main document. This way, a normal hyperlink can still function,
>> the browser won't even send the #!! piece to the server when
>> requesting the page, so most analytics won't notice it (although .js
>> can see / report it, so that's not guaranteed).
>> So the choice of property in rel= can be tuned, depending on whether
>> the link is to a page or (from an rdf perspective) the thing described
>> by the page. Most people would just see a link and 3 more chars of
> It introduces an additional burden on FOAF processors. You could
> sometimes add entailed triples, or you could have two set of queries
> for every page/concept type property, but neither of those options
> seems great.
Yes, this problem haunts us in general. We can't pretend 'ordinary'
human-facing URLs don't exist and aren't used. They are the things
that are bookmarked, sent to friends, tagged on delicious, printed on
business cards, updated regularly, posted on blogs, managed in Drupal,
indexed by Google, etc etc. And that's not going to change in a hurry.
And since the TAG decision on HTTP-range-13, those bookmarkable URIs
aren't considered as eligible to be directly identifiers for the
things described in the content (without a bookmark-busting 303
redirct, or a #).
We can't plausible advocate that people stop linking to wikipedia and
start linking to dbpedia, for example. At least not in user-facing
HTML-based markup. So we have a diversity in the data right from the
start. People aren't their homepages or blogs, and things aren't the
pages that describe them. This issue has been at the heart of the
'semantic for the Web' effort since 1994 (eg. see slides in
Given this inevitable burden, ie. that sometimes we have information
couched in terms of IDs for things, sometimes indirectly via other
IDs, what can we do about it? One strand of thinking common in the
tbd: URI scheme, foaf:primaryTopic property, and this hashbang
suggestion, is that we can avoid needless fragmentation (er sorry for
the pun) of information if we have some common conventions for making
identifiers for things out of identifiers for documents; and for
detecting those conventions when they're used by others.
> There will always be cases where you can't go from a concept to a
> page, because the concept given has no obviously derivable page http://foo.example/myconcenpt#ThatIJustThoughtUp
> - Steve
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
More information about the foaf-dev