Re: WebID default serialization for WebID 2.x

On Sun, 23 Jan 2022 at 12:06, Martynas Jusevičius <martynas@atomgraph.com>
wrote:

> Yes.
>
> curl -k -H "Accept: text/turtle"
> https://kgdev.net/admin/acl/agents/9b0674c0-6904-11ec-aa02-1239e594f8ef/


Thanks for sharing

This is a perfect example of why WebID needs to be deployed better

Most people clicking that link will get what they see as an error.  In that
it doesnt display ordinarily in the browser, because the SSL certificat is
invalid.  This will also prevent many ajax requests

When I look at semantic data in the HTML

<meta name="og:title" content="Martynas Jusevicius">
<meta name="twitter:title" content="Martynas Jusevicius">

Which is great, but the rest of your WebID details is missing:

It neither matches what is seen in curl or in:

https://kgdev.net/admin/acl/agents/9b0674c0-6904-11ec-aa02-1239e594f8ef/?accept=text%2Fturtle

(which is a strange pattern)

And gives:

        <http://xmlns.com/foaf/0.1/name>
                "Martynas Jusevicius" .

Is this even a webid, as you should be denoting an agent.  The type is:

https://w3id.org/atomgraph/linkeddatahub/admin#Agent

Which doesnt give back any indication of an Agent no matter how much curl
you throw at it

In summary.  Issues with this deployment:
- certificate leads to browser errors
- cross origin requests will break
- I didnt see any CORS headers
- the Agent type does not dereference
- different content types give different semantic data

And this is deployment with expert level knowledge.  I got this in 5
minutes of looking

Can you see now why there is a need for better deployment patterns, and
instructions, and making this simpler?


>
>
> This reminds me of something that is probably underspecified in the
> current draft, namely that the Agent and the PublicKey can in
> principle be in separate RDF documents.
>
> On Sun, Jan 23, 2022 at 11:30 AM Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> >
> >
> >
> > On Sun, 23 Jan 2022 at 10:49, Martynas Jusevičius <
> martynas@atomgraph.com> wrote:
> >>
> >> Hi,
> >>
> >> If one specific RDF serialization would be mandated, I can say already
> >> now that we would not support such WebID spec. Our servers can produce
> >> any format Jena supports, plus HTML, for every RDF resource, so that
> >> would not be possible even if we wanted to.
> >
> >
> > Do you already support the current WebID 1.x spec?  Because it mandates
> turtle right now:
> >
> > "must be available as text/turtle [turtle], but may be available in
> other RDF serialization formats"
> >
> >>
> >>
> >> Top Linked Data researchers pretending not to understand content
> >> negotiation raises my eyebrows. It has been a feature of HTTP since
> >> forever.
> >>
> >> The effort to dumb down RDF Linked Data to make it more accessible to
> >> some mythical "developers" continues to amaze me. Those developers
> >> most likely do not even need Linked Data as they don't have the sort
> >> of problems it addresses.
> >> We shouldn't be looking at easy solutions, we should be looking at
> >> first principles and the *right* solutions.
> >>
> >>
> >> Martynas
> >>
> >> On Sun, Jan 23, 2022 at 2:23 AM Sebastian Hellmann
> >> <hellmann@informatik.uni-leipzig.de> wrote:
> >> >
> >> > Hi Jonas,
> >> >
> >> > On 22.01.22 01:09, Jonas Smedegaard wrote:
> >> >
> >> > Quoting Sebastian Hellmann (2022-01-22 00:21:49)
> >> >
> >> > Hi Jonas,
> >> >
> >> > a question: I am having trouble finding the current spec. Also I can
> not
> >> > find anything about NetID. See more inline.
> >> >
> >> > Current draft of the WebID spec is this:
> >> > https://www.w3.org/2005/Incubator/webid/spec/identity/
> >> >
> >> > Are you sure that this is a spec? I see it as an inspirational
> document on how a spec could look like, if you spent the effort to work on
> it.
> >> >
> >> > I saw that you forked the spec into github, but I would actually
> propose to start from scratch and just do cherry picking from this
> document. When we implemented it, we had to rely mostly on personal
> experience and things we remembered from Henry Story's presentations, when
> he was on WebID tour over a decade ago, AKSW people and OpenLink docu.
> >> >
> >> > See .e.g:
> >> >
> >> > "3. The WebID HTTP URI"  -> Is HTTPS not mandatory? Will we be able
> to move forward by including HTTP in any form?
> >> >
> >> > "There are two solutions that meet our requirements for identifying
> real-world objects: 303 redirects and hash URIs."  -> how do 303 redirects
> identify real-world objects? URIs that resolve to 303? hash URIs might also
> resolve to 303.
> >> >
> >> > "Personal details are the most common requirement when registering an
> account with a website. Some of these pieces of information include an
> e-mail address, a name and perhaps an avatar image, expressed using the
> FOAF [FOAF] vocabulary. This section includes properties that SHOULD be
> used when conveying key pieces of personal information but are NOT REQUIRED
> to be present in a WebID Profile:"
> >> >
> >> > <#me> a owl:Thing.
> >> >
> >> > 1. Hash URI ✅
> >> > 2. Turtle   ✅
> >> > These are all MUST requirements, I could find. Doesn't even need the
> foaf:PersonalProfileDocument declaration,  so ✅ valid WebID
> >> >
> >> > "5.4 Privacy" -> is this in scope of "how to publish WebIDs"?
> >> >
> >> > 6. Processing the WebID Profile: The Requesting Agent needs to fetch
> the document, if it does not have a valid one in cache.
> >> >
> >> > It is recommended that the Requesting Agent sets a qvalue for
> text/turtle in the HTTP Accept-Header with a higher priority than in the
> case of application/xhtml+xml or text/html, as sites may produce HTML
> without RDFa markup but with a link to graph encoded in a pure RDF format
> such as Turtle.
> >> > For an agent that can parse Turtle, rdf/xml and RDFa, the following
> would be a reasonable Accept header:
> >> >
> >> > Accept:
> text/turtle,application/rdf+xml,application/xhtml+xml;q=0.8,text/html;q=0.7
> >> >
> >> > <rhetorical>What?</rhetorical>
> >> >
> >> > -- Sebastian
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
>