Re: WebID-JSON-LD Spec

On Wed, 08 Nov 2023 16:28:18 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> I've made a stab at the WebID JSON-LD spec.
> 
> The main question I have is whether to use primaryTopic, with a nested
> object.  Or to use isPrimaryTopicOf : "", which I believe would allow one
> object.  This latter simplification will be useful elsewhere, so I'm
> leaning towards it.  But I'm unsure whether or not there are any gotchas
> related to this design decision.

Looks good and simple. We should document each of the FOAF terms that
are mapped by this selective context so you don't have to read FOAF
specs for the basics.

There is a bug in that you say "@type": "webid:Agent" which should jsut
be "Agent" to work with that context.

FOAF has:

> Note that there is no inverse of foaf:primaryTopic. We could have
> created a more general super-property of foaf:homepage to serve this
> purpose, but there is little obvious value in doing so. 

As I think a WebID-JSON-LD can be very simple then we should NOT
need to use @graph: [] listing to include the PersonalProfileDocument as
a separate object.

You can either use JSON-LD context  declaration:

  "profileOf": { "@reverse":  "@id": "foaf:primaryTopic" }, 

..or make the PersonalProfileDocument top element (as self-declaration),
and, I propose, without "@id":

{
  "@context": "https://w3id.org/webid",
  "@type": "PersonalProfileDocument",
  "primaryTopic": {
    "@id": "#me",
    "@type": "Person",
    "name": "Stian Soiland-Reyes"
  }
}

If we need a PersonalProfileDocument @id or not, that depends on if we
think a WebId-JSON-LD is separate from other JSON-LD documents, which
depend on how it is deployed.  

However the main reason PersonalProfileDocument is in there to start
with is to find a "root" in case there are other people mentioned in
foaf:knows -- we can say there should only be one
typed PersonalProfileDocument in a WebID-JSON-LD document.

BTW, as a general rule of thumbs on properties that have inverses I
would use "outgoing" properties as authorative from that resource (:this
hasPart :all, :my:, :parts) and prefer the inverses for incomplete
back-references (:this isPartOf :otherCollection). However we have two
potential top-nodes here and we don't have foaf:isPrimaryTopic.




Q: Why no @id? Aren't blank nodes bad?

Well, if you know well which identifier to assign, please add @id. But I
assume WebID-JSON-LD is for a more lightweight approach not requiring
people to learn HTTP-Range-14 etc.

The above would work equally well in a HTML <script> tag where "@id": ""
would point to the HTML document (and not the JSON-LD script). In
addition this would then not cause url crash issues if 
there is no foaf.jsonld file separate from the home page, which may
appar with foaf:homepage but is not needed for WebID. 

For instance, for ORCID we already have
https://orcid.org/0000-0001-9842-9718 directly as the identifier for the
person, so there is no separate personal profile document. But in the
FOAF you get (Accept: text/turtle)  we had to fake a new URI
http://pub.orcid.org/orcid-pub-web/experimental_rdf_v1/0000-0001-9842-9718
just to name the PersonalProfileDocument.

Compare with the JSON-LD you get with schema.org:

curl -H "Accept: application/ld+json" -L https://orcid.org/0000-0001-9842-9718

{
  "@context" : "http://schema.org",
  "@type" : "Person",
  "@id" : "https://orcid.org/0000-0001-9842-9718",
  "mainEntityOfPage" : "https://orcid.org/0000-0001-9842-9718",
  "name" : "Stian Soiland-Reyes",
  "givenName" : "Stian",
  "familyName" : "Soiland-Reyes",
  "alternateName" : [ "stain", "@soilandreyes", "Stian Soiland", "Stian Søiland" ],
  "address" : {
    "addressCountry" : "GB",
    "@type" : "PostalAddress"
  },
  "@reverse" : {
    "funder" : [ {
      "@type" : "Organization",
      "@id" : "https://doi.org/10.13039/501100000780",
      "name" : "European Commission",
      ...


Here I am a person and the "main entity" (equivalent of primaryTopic) of
myself as a CreativeWork, which is not ideal, however schema.org type
hierarchies are not so strict.. ;)

But at least if we want ORCID to augment this,  to also have a
Webid-JSON-LD profile (you could find both using Signposting perhaps),
then these two should not be in conflict on the identifier side, I would
hate to see a new identifier https://orcid.org/0000-0001-9842-9718#me
sneak in!




-- 
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
 Please note that I may work flexibly - whilst it suits me to email now,
 I do not expect a response or action outside of your own working hours.

Received on Wednesday, 8 November 2023 16:38:41 UTC