PersonShape

[elf-pavlik]

This is the first one I will adjust solid-efforts to use. I have a few comments under the snippet 👇

In #15 we have

shape :PersonShape -> ex:Person ;
	sh:name "Person"@en {
	ex:name xsd:string [1..1] %
		sh:name "name"@en
	% .
	ex:contactEmail xsd:string [0..1] pattern="^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$" %
		sh:name "contact email"@en ;
		sh:description "if you wish to share the email privately to ODI, leave this blank & contact solid@theodi.org"
	% .
	ex:webid xsd:string [0..1] %
		sh:name "WebID"
	% .
	ex:forumHandle xsd:string [0..1] %
		sh:name "forum handle" ;
		sh:description "your handle/nick on the Solid Forum"
	% .
	ex:matrixHandle xsd:string [0..1] %
		sh:name "matrix handle" ;
		sh:description "your handle/nick in the Matrix chatrooms"
	% .
	ex:description xsd:string [0..1] maxLength=280 %
		sh:name "description"@en
	% .
	ex:logo IRI [0..1] %
		sh:name "logo"@en
	% .
	ex:landingPage IRI [0..1] %
		sh:name "landing page"@en
	% .
	ex:repository IRI [0..1] %
		sh:name "repository"@en
	% .
	ex:resourcesWanted xsd:string maxLength=280 %
		sh:name "resources wanted"@en ;
		sh:description "funding, employees, interns, partners, separate multiple with a blank line"
	% .
	ex:resourcesOffered xsd:string maxLength=280 %
		sh:name "resources offered"@en ;
		sh:description "funding, mentorship, collaboration, offered; separate multiple with a blank line"
	% .
}

1. I agree that name should be the only required property
2. logo & description SGTM, I will most likely just use those two and the name for what I need ATM
3. I don't see need for webid as property, if someone has WebID we will simply use it as the subject/object (related to Unique temporary identifiers #7)
4. I find forumHandle too specific, instead I would look for a generic property in lines of rel-me and then apps could use regex to detect one for the solid forum. This looks pretty easy https://forum.solidproject.org/u/elf-pavlik, if we really want to define something very specific solidForumHandle for Solid Forum, it should at least be an IRI rather than a string. In the long run we should allow setting WebID in the discourse running Solid Forum so that information can be extracted from there. In that case this specific property could become archaic.
5. matrixHandle sounds ok since it is protocol specific, in contrast to Solid Forum. It also seems to have a very specific format MXID (eg. @elf-pavlik-53f689c8163965c9bc1ffb15:gitter.im) can we add a regex to enforce it?
6. repository i honestly don't know what that is supposed to mean, something like https://github.com/msporny/dna ? 😉
7. resourcesWanted & resourcesOffered, I think eventually they will need to become IRIs and shapes based on something like https://schema.org/Offer and https://schema.org/Demand I think this will be a major task on its own. As long as people realize that we will not be able to migrate their tweet size strings and they will need to recreate that part once it gets changed, I would just leave it as is and create a cleaner approach when we are ready to focus on it.

[jeff-zucker]

3. I don't see need for webid as property, if someone has WebID we will simply use it as the subject/object (related to Unique temporary identifiers #7)

I agree that eventually, if we have a WebID or ClientID, we should use it as the subject. I do not agree that we should remove it as a predicate. People will need to be able to enter and change their own and others need to be able to see it.

4. I find forumHandle too specific, instead I would look for a generic property in lines of rel-me and then apps could use regex to detect one for the solid forum. This looks pretty easy https://forum.solidproject.org/u/elf-pavlik, if we really want to define something very specific solidForumHandle for Solid Forum, it should at least be an IRI rather than a string. In the long run we should allow setting WebID in the discourse running Solid Forum so that information can be extracted from there. In that case this specific property could become archaic.

I don't have a strong opinion. I think Tim has started to add something like this in the SolidOS profile pane, I'll take a look at what he's doing.

5. matrixHandle sounds ok since it is protocol specific, in contrast to Solid Forum. It also seems to have a very specific format MXID (eg. @elf-pavlik-53f689c8163965c9bc1ffb15:gitter.im) can we add a regex to enforce it?

Most people will have no idea how to find their actual handle. The shortened form @elf-pavlik is sufficient to find you once they get to Matrix. I am not in favor of requiring the long form, but don't feel strongly about it.

7. repository i honestly don't know what that is supposed to mean, something like https://github.com/msporny/dna ? 😉

A place where code and other information about a project is stored. This is distinct from a landingPage, which may have pointers to the code, but is not expected to be a place one can download things from. Many projects (for example Solid) have both. solidproject.org is a landingPage, github.com/solid is a repository. I want to know about both and will go to both depending on what I am looking for.

8. resourcesWanted & resourcesOffered, I think eventually they will need to become IRIs and shapes based on something like https://schema.org/Offer and https://schema.org/Demand I think this will be a major task on its own. As long as people realize that we will not be able to migrate their tweet size strings and they will need to recreate that part once it gets changed, I would just leave it as is and create a cleaner approach when we are ready to focus on it.

Agree. Yes I was thinking along the Offer/Demand lines. And yes, a bit too complex to handle now, but needs work in the future.

[jeff-zucker]

A bigger question about the Person shape is how we make sure to have interoperability with vcard:AddressBooks. If we use exactly their fields plus sone of our own, we ought to be able to point to an AddressBook as one of the sources of data for a Catalog and directly consume it. Even if we do not use vcard to structure our Person records, it should be very easy to write a script to convert from vcard to whatever we use. In with we need interoperability with AddressBooks.

[elf-pavlik]

People will need to be able to enter and change their own and others need to be able to see it.

Could you explain why do you see ex:webid predicate needed for any of this? I also imagine that all types of resources have those requirements not only Person

The shortened form @elf-pavlik is sufficient to find you once they get to Matrix.

I actually created both

• @elf-pavlik-53f689c8163965c9bc1ffb15:gitter.im
• @elf-pavlik:matrix.org

but currently only use the gitter one. There are more people in solid community which have the same handle on more than one matrix idp. To avoid 'garbage in' I would prefer that date entry provides short instruction for where to copy the full MXID. I assume that bot which backs up Matrix chatrooms to a solid pod uses full MXID, it would be good to check.

A place where code and other information about a project is stored.

Does it mean that it is currently used on Person shape by mistake?

A bigger question about the Person shape is how we make sure to have interoperability with vcard:AddressBook

I think this is an issue for https://github.com/solid/contacts and catalog should contribute and track it.
I see an issue with describing a person directly vs indirectly (via card) but let's not get into it here.

[jeff-zucker]

Could you explain why do you see ex:webid predicate needed for any of this?

Well, one problem is this: suppose I want an app to display a person's WebID, but the only way to find that WebID is to look at the subject of the Person's record. But some people don't have WebIDs so the subject is a UUID or some such. How is the app to know whether the subject is a WebID or some sort of UUID or other random ID? It can't AFAIK, so there would be no way to programatically say whether a given person actually has a WebID or not. We'd either have to not display WebIDs or display, along with the real WebIDs, some random IDs as if they were WebIDs, which they are not.

Could you explain why you object to having it as a predicate?

A place where code and other information about a project is stored.

Does it mean that it is currently used on Person shape by mistake?

Maybe they store their DNA there :-). But, for example I have a github personal page which points to the code repos I have so I might list that as my repo but have a text-based landing page somewhere else. The landingPage is to describe me, the repository is to hold and point to my code. If you like, we can add something like this to the form prompts:

   landing page ____ (the main place a resource is described - a web page, wiki, etc.)
   repository _____ (a storage site for code and/or process documents such as charters, minutes) 

A bigger question about the Person shape is how we make sure to have interoperability with vcard:AddressBook

I think this is an issue for https://github.com/solid/contacts and catalog should contribute and track it. I see an issue with describing a person directly vs indirectly (via card) but let's not get into it here.

Agree.

[elf-pavlik]

But some people don't have WebIDs so the subject is a UUID or some such. How is the app to know whether the subject is a WebID or some sort of UUID or other random ID?

I think #7 solves that by using urn:uuid: for temporary identifiers. Even when using fragments, one can still use a regex to check if it is a temporary identifier.

Could you explain why you object to having it as a predicate?

It would only be used if someone actually has WebID, so subject and object would be always the same, for example <https://sam.example> ex:webid <https://sam.example>. I don't think we need that just to avoid confusing temporary identifiers with actual WebIDs.

The landingPage is to describe me, the repository is to hold and point to my code.

Any code that is relevant to solid would have record in catalog anyways. All that software would be linked to your WebID as well and catalog app would allow smooth navigation.

Maybe they store their DNA there :-)

In general I would like to avoid adding vague and ambiguous properties directly to the catalog shapes.

[jeff-zucker]

Could you explain why you object to having it as a predicate?

It would only be used if someone actually has WebID, so subject and object would be always the same, for example <https://sam.example> ex:webid <https://sam.example>. I don't think we need that just to avoid confusing temporary identifiers with actual WebIDs.

This does not seem like a pressing objection. I am still in favor of keeping the webid predicate.

The landingPage is to describe me, the repository is to hold and point to my code.

Any code that is relevant to solid would have record in catalog anyways. All that software would be linked to your WebID as well and catalog app would allow smooth navigation.

There are many cases in which a general description aimed at the public is usefully distinguished from a code repository. Nothing you have said changes my mind about the need for both predicates.

[elf-pavlik]

I am still in favor of keeping the webid predicate.

I'd like to separate problems from proposed solutions, in this discussion I saw you mentioning two problems where you consider ex:webid as potential solution.

But some people don't have WebIDs so the subject is a UUID or some such. How is the app to know whether the subject is a WebID or some sort of UUID or other random ID? It can't AFAIK,

People will need to be able to enter and change their own and others need to be able to see it.

@jeff-zucker could you confirm that you propose ex:webid as possible solution to those two problems/requirements?

1. Are those two problems/requiremts specific only to data that conforms to PersonShape or common to data that conforms to other shapes in the catalog?
2. Are there any other problems/requirements that you try to address with proposed ex:webid?

[jeff-zucker]

I have said where I stand. I am not interested in having an extended debate with you about it. You have not brought out any significant harm from maintaining the predicate and until you do I will continue to advocate for it remaining,

[jeff-zucker]

Additionally, a predicate for we webid is used in the contacts shape which you previously referenced. I think we should follow that example for how to portray the URIs. The contacts Shape includes a WebIDShape : https://github.com/solid/contacts/blob/d853415c0d1bd22d325ccd83725b4d16b506ebed/shapes/contacts-shapes.ttl#L191

[elf-pavlik]

@jeff-zucker : A bigger question about the Person shape is how we make sure to have interoperability with vcard:AddressBook

@elf-pavlik: I think this is an issue for https://github.com/solid/contacts and catalog should contribute and track it. I see an issue with describing a person directly vs indirectly (via card) but let's not get into it here.

@jeff-zucker: Agree.

---

If we let vcard aside for now, which seems to use a class :WebId not a property :webid.

I have impression that you look for something similar to JSON-LD @id, which allows to work with a graph in entity-attribute-value perspective, where @id is a special attribute which doesn't map to a predicate.

I try to understand it based on what you shared so far in this conversation. I don't know how you generate the forms, but maybe handling the focus node, that is validated against the shape, as another input is also tricky. Maybe @jeswr could share his experience with generating forms from shapes.

I asked twice is it specific to PersonShape or more general, since the two reasons you mentioned here seem to be more general requirements to me. All resources in the catalog can possibly start with temporary identifier and later migrate to a permanent URL in a namespace external to the catalog.

[jeff-zucker]

f we let vcard aside for now, which seems to use a class :WebId not a property :webid.

I don't need it to be a property, the vcard way would work. We could replace the webid, clientid, landingPage, and repository predicates with something like

<#OrganizationA> vcard:url 
   [ a vcard:HomePage; vcard:value <homepage-uri> ],
   [ a vcard:WebID; vcard:value <webid-uri> ],

I previously suggested using typed links like that.

I try to understand

A WebID and a ClientID, are not like any other identifiers in the Catalog, they have meaning in themselves to the end user and they are a specific kind of destination in themselves. That means, in my mind, treating them the same as other data intended for the end user. I don't know about Jesse's or Ieben's forms, but yes, my forms are based on being able to go directly from the shacl to the form so adding the parsing of the value of the subject seems like it operates on top of the shacl rather than through it.

I asked twice is it specific to PersonShape or more general,

It applies to anything which can have a WebID or a ClientID, specifically to Person, Organization, and Software. Oops, I left WebID off of Organization. Will re-insert it and it can be removed with the others if we go that way.

All resources in the catalog can possibly start with temporary identifier and later migrate to a permanent URL in a namespace external to the catalog.

But WebID and ClientID are destinations in themselves - knowing that something is a WebID or ClientID means both that we know where to look and we know what format to expect the link to lead to and it is guaranteed to be accessible as RDF. None of that can be said for other kinds of identifiers AFAIK.

[elf-pavlik]

Thank you @jeff-zucker I need some time to think about it.

For now just for the record. Solid-OIDC context actually aliases @id to client_id
https://github.com/solid/vocab/blob/main/solid-oidc-context.jsonld#L7-L10

"client_id": {
      "@id": "@id",
      "@type": "@id"
    },

This way once parsed the value (IRI) is used as a subject/object and there is no client_id property/predicate at all.

[elf-pavlik]

A WebID and a ClientID, are not like any other identifiers in the Catalog, they have meaning in themselves to the end user and they are a specific kind of destination in themselves. That means, in my mind, treating them the same as other data intended for the end user. I don't know about Jesse's or Ieben's forms, but yes, my forms are based on being able to go directly from the shacl to the form so adding the parsing of the value of the subject seems like it operates on top of the shacl rather than through it.

I had quick chat with @jeswr also using my JSON-LD @id example from my comment above 👆

From what I understood from his explanation, disclaimer that myself I don't generate forms from SHACL, when we have form for a Person, input for their WebID would by handled by the viewer but outside of the shape itself. We seemed to agree that introducing ex:webid property for a Person doesn't seem like a correct way to model the data.

---

We probably want to address #7 as we discuss identifying records and upgrade path from temporary identifiers to permanent identifiers in external namespaces, which would be the first requirement for self publishing descriptions.

---

I think we can discuss

• How should we handle links from an asset to its online access point(s)?  #2 (typed links)

separately. I'm going to respond to your snippet from #16 (comment) in that issue