Addition of solid classes Email and Telephone

[hkir-dev]

with reference to SolidOS shapes https://github.com/solid/shape-generation-artefacts/tree/main/shapes

[langsamu]

1. I would advise against this pattern of using singular on one hand and a null coalesce for default value on the other hand. singular is a utility method that expects (requires) one and only one statement with the given subject and predicate. IOW, there is exactly one statement matching ?s vcard:hasValue ?o or else I throw (source).
2. I would aim to keep 'mapping properties' separate from other logic, i.e. a property should consist either of invocations of the utility methods or of other logic (like assigning defaults). The reason is that mapping properties could/would be generated.
3. I have not thought about whether a default value for this property is reasonable at all. I have afeeling that not having defaults is somehow better, simpler. But again, this is not a very informed opinion.

[langsamu]

I don't know anything about how this vocabulary is used in the Solid community it's history there or best practices that migh be in use, but I see a potential problem with this shape in the context of the vCard Ontology.

vcard:email is a datatype property while vcard:hasEmail is an object property.
vcard:email will have a literal object or a blank node with a vcard:value property, itself a literal.
vcard:hasEmail will have a resource object or a blank node with a vcard:hasValue property, itself a resouce.

In this code, both of these are handled using the Email mapping class. Thst's not a problem, but then that class should be smarter.

In any case, I don't think we are doing justice to the versatility of vCard. In my understanding, all of the following are valid shapes:

[ :hasEmail <mailto:user@example.com> ] .
[ :hasEmail [ :hasValue <mailto:user@example.com> ] ] .
[ :email "mailto:user@example.com" ] .
[ :email [ :value "mailto:user@example.com" ] ] .

It is entirely possible to map any usage scenario to JavaScript classes using a combination of mapping properties and other logic. Here I'm just highlighting what seem like discrepancies. Happy to help with proposed programming constructs once there is clarity on what the shape we're mapping is.

If I'm calling out things that are irrelevant or have already been clarified then sorry.