i am considering whether to markup my webid thing with vcard properties and honestly i am not finding it a good experience. vcard is just so bad. vcard-rdf is also bad because vcard itself is bad. it's a not-fully-thought-out concept and there are things missing in a lot of places

i know rdf is infamously hard to grasp if you go by the memes but how hard can it really be to grasp the difference between a data property and an object property? just because something is a uri doesn't mean it is necessarily the thing that uri represents.

case in point: UID is defined as a uri. vcard:hasUID is defined as an object property. this is wrong, it should be a string of xsd:anyURI. if you treat it as an object, then you have a circular reference that my uid is myself.

i think the critique of rdf that holds up the best is that people approach it with insufficient rigor; in a lot of cases to reach correctness you have to be way more formal than a lot of people are used to being. i'd argue that this mostly translates into less robustness or lower tolerance for being lazy and vague

i don't buy the YAGNI argument because it is clearly useful to me as a technology, but its usefulness is directly harmed by incomplete or incorrect concept modeling

idk if this is even correct conceptually

something like GENDER:N;nonbinary seems to imply a vcard:hasGender some blank node whose type is None and which hasValue "nonbinary". at least, that's how i'm treating it right now. but i could also see it being just as valid to have vcard:hasGender None directly, if there is no additional value associated. but that's an ambiguity which should not exist in the first place, it should be unambiguous ideally. of course there's no guidance regarding this...

rfc 6350 has seemingly invalid ABNF