Re: WebID-JSON-LD Spec

Hi Melvin, Stian,

I punched both your examples into https://json-ld.org/playground/ and 
they are returning nothing (Melvin's example from github doc) or

_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://xmlns.com/foaf/0.1/PersonalProfileDocument> .
_:b0 <http://xmlns.com/foaf/0.1/primaryTopic> _:b1 .

(Stian's example)

Could you send an example that is working with the N-Quads tab from the 
playground or is the playground buggy?

How did you parse it?

-- Sebastian

On 11/8/23 17:38, Stian Soiland-Reyes wrote:
> 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!
>
>
>
>

Received on Wednesday, 8 November 2023 19:50:35 UTC