-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid the use of sh:IRI
for contact point
#130
Comments
why would you require name and email only when the contact point is blank? |
I don't understand. What else do you think is necessary? |
my understanding is that name and email are required on a contact point only when the contact point is blank. Why they are not needed also when the contact point is an IRI? |
Ah, gotcha. I somehow limited the logic to IRI meaning remote resource. |
now I get the rationale and it makes sense to me. In a sense, choosing blanks is often a way to express that the data 'belongs' to the referencing object (as in concise bounded descriptions which include blanks and instead stops at IRIs) |
TBH, the case of contact point may not even make sense as a remote resource in the first place but let's not got there now |
The constraints on
schema:contactPoint
require the value to be an IRIcube-link/validation/standalone-cube-constraint.ttl
Lines 46 to 49 in 2b69ad5
Some other properties too, are constrained like that. I propose to relax this to allow blank nodes. Possibly as an alternative, where it's either IRI or a blank with deep description using
sh:node
. For the standalone cube I expectschema:name
andschema:email
at the leastThe text was updated successfully, but these errors were encountered: