Re: What is a WebID?

čt 9. 11. 2023 v 14:54 odesílatel Sebastian Hellmann <
hellmann@informatik.uni-leipzig.de> napsal:

> Hi Nathan,
>
> sorry, I was too compact on this one.  I acknowledge the addressed problem
> of HR14 that it could be useful to distinguish between documents and
> things. I also see that it adds a whole layer of complexity and therefore
> barriers to adoption.  Then on top of that, I don't know or remember any
> use case where the distinction between docs and things is very central. For
> me getting the data is always key, so the Profile Doc triples are useless
> overhead, plus we also don't have a standardized versioning mechanism in
> place, e.g. 303 redirecting to docs with version in URI.
>
> From the client / retrieval side and also the publisher side the 303  just
> adds overhead and potential errors when sameAs linking. My proposal to
> simplify was to use a more REST API-like approach:
>

FWIW: when we defined WebID at TPAC, TimBL explicitly said no 303s.  I
asked why.  He said: "Because redirects are a pain".  There was later
lobbying on the list to include 303s.  I think one argument was the dbpedia
used it.  I remember many conversations with kingsley about why dbpedia
(and other systems) needed 303s.  I could never fully understand it but he
was convinced it was the only way to scale  I'd still have preferred #'s
for things, but a definitive argument for 303s I've never seen laid out in
a way I could fully understand.


> WebID: https://databus.dbpedia.org/kurzum#this
>
> curl -H "Accept: text/turtle" "https://databus.dbpedia.org/kurzum"
> <https://databus.dbpedia.org/kurzum>
>
> Option a) return 200 with header Location:
> https://databus.dbpedia.org/kurzum.ttl
>
> Option b) return 200 and put all the info about what's the document /
> information resource / versioning in the delivered data.  (note that most
> implementations would leave that out, just returning the data, not the info
> about the docs).
>
> I am aware that this blurs the line between docs and entities,
> non/information resources.  The thing is that I really don't know see any
> disadvantages from the practical side to implement it this way, i.e. like
> any other REST API.
>
> -- Sebastian
>
>
> On 11/9/23 12:18, Nathan Rixham wrote:
>
> On Thu, Nov 9, 2023 at 11:00 AM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>> * simpler Linked Data:  you are aware that HTTP-range-14 can be tackled
>>> post request, right? curl -H "Accept: text/turtle"
>>> "https://databus.dbpedia.org/kurzum#this" even without a 200/Location
>>> Header.
>>>
>>
>> Trying to understand HR14 tackled post request?  Adding "#this" I know
>> about, and seems like a smart thing.  Unsure #this is documented anywhere,
>> maybe that's a good thing to do (A Note perhaps?)
>>
>
> HR14 pertains to URIs without a #fragment part. The contention was that
> URIs without a #fragment should be understood to be referring to documents,
> not cars.
>
> HTTP does not support #fragment's in the fundamental protocol, they are
> stripped out.
>
> curl -H "Accept: text/turtle" "https://databus.dbpedia.org/kurzum#this"
> ==
> GET /kurzum HTTP/1.1
> > Host: databus.dbpedia.org
>
> no #fragment.
>
> The conneg, as outlined in Sebastian's example, is not HR14.
>
> Best, Nathan
>
>
>
>
>