Re: Using "Punning" to Answer httpRange-14

On Mon, May 14, 2012 at 1:58 PM, Michael Brunnbauer <brunni@netestate.de> wrote:
> I think the whole semantic web right now is by definition subject-sense,
> object-sense and httpRange-14 restricts the sense of a 200 URL to it's content.

that's interesting. i think there is no default, and most people don't
understand why this is a problem, so they don't think about it until
they encounter a bug in their data. so the default i would say is to
assume it will magically work, and that if you use links in the way
you intend them, everybody will understand you without the need for
further communication.

in a lot of cases, this will work. for instance, an 'author' or
'created' element in a web page is pretty much universally understood
as subject-content, subject-sense. so you have to think about what the
author of the web page intended.

then there is the 303s camp that switches the default to
object-content (and uses 303s for object-sense). because there are
people outside the 303s camp (and there always will be, and we need to
tolerate that), even people in the 303 camp will have to try to
understand what a data provider means.

then there is the hash-uri-rule camp that also switches the default to
object-content, if the URI is a whole document, but leaves it as
object-sense if the URI points to a fragment of a document. likewise,
people in this camp will also have to interpret what a data provider
means with a link rel. Say i publish a blogpost with a link in it,
with rel 'author' and href my foaf profile (but i omit the '#me' at
the end). according to the hash-uri-rule, that means my foaf profile
wrote the blogpost. what should a hash-uri-rule-compliant client do
with that? say "this blogpost was written by a foaf file"? No, it
should be tolerant of other world views and say "this blog post was
written by so and so", and then maybe emit "Warning: document not
hash-uri-rule compliant".

What i mean is: i think there is no default. we have to live with
that, and stop trying to define one. everybody does their own thing,
and we need to make clients robust, and tolerate all three world
views. maybe a client could have a setting saying 'hard error when you
get a document where a 303 was expected', or 'assume hash-uri-rule
when interpreting links'.

but i think we should stop trying to define an obligatory 'default',
and just accept that there will be some data that uses these common
practices, and some data that uses other common practices.

then when we write vocabulary spec, we should simply be very explicit
about what these specs are trying to say. i think it's a brilliant
solution that embraces the 'aliveness' of the web as Kingsley said.


cheers,
Michiel

Received on Monday, 14 May 2012 12:50:06 UTC