- From: Pat McBennett <patm@inrupt.com>
- Date: Mon, 28 Mar 2022 14:13:36 +0000
- To: Rob Brennan <rob.brennan@adaptcentre.ie>
- Cc: "Harshvardhan J. Pandit" <me@harshp.com>, Beatriz Esteves <besteves@delicias.dia.fi.upm.es>, public-dpvcg@w3.org
- Message-ID: <CABgQ8mL+rKOExQo4fOq9xWFr07KG4qWbuysQdjiv=m+raJG7Qg@mail.gmail.com>
Hi Harsh/Rob, I'm delighted to be having this discussion, as I do think it's an important topic. So firstly, I'd agree that today there are actually *2 conventions* - one using 'has' and 'is' prefixes, and the other not using them. But I'd suggest that the reasons for *not* using prefixes are: - Consistency - i.e., 'has' and 'is' simply can't be applied to all terms (and still have the term name be easily understandable in English). An example from DPV itself is the property `mitigatesRisk <https://w3c.github.io/dpv/dpv/#mitigatesRisk>`. Therefore it seems to often be a subjective call as to *when* to use them, and when not to use them. Or if you want to be consistent and use them 'everywhere' you have screw around with the English - e.g., `residesAt` might have to become `hasResidenceAt` or `isResidentAt`. Whenever we have subjective judgement calls like that, it generally leads to confusion (i.e., did the vocab creators use 'has', or 'is', or nothing at all...?). So I think the only way to have consistency is to state the guidance as 'not using term name prefixes' (or use a *really* generic prefix, see next point). - To prevent noise. This becomes evident in examples like the 11 base DPV properties here <https://w3c.github.io/dpv/dpv/#baseontology-properties>, or the 14 Entity DPV properties here <https://w3c.github.io/dpv/dpv/#entities-properties> - i.e., all 25 terms start with 'has', which means it acts as just a noise word (i.e., what value is it bringing at all?). If we really need to clearly distinguish between terms for Properties and terms for Classes (and I'd suggest that that rather questionable, since 'the *other* Linked Data convention' seems pretty fine by not using them at all), then I'd suggest using 'prop' might be a better noise word. Then we'd only have one word instead of two, but I think a 'prop' prefix on literally every single vocab property highlights even more the 'noisey-ness' of using any prefix at all. - This all reminds me of the flamewars years ago around Hungarian notation <https://en.wikipedia.org/wiki/Hungarian_notation> in C and C++. I'm not sure if that's particularly relevant here or not to be honest, but it certainly 'feels' very similar (and I think the end result of all that debate back then was to be extremely careful and limited in one's use of prefixes (i.e., see the Notable opinions at the end of that Wikipedia article)). - It also saves a few bytes per term! I'd also note that in Schema.org (i.e., the most prominent vocab out there today perhaps!), out of nearly 1,500 properties there are only 31 'isXXXX' and 28 'hasXXXX', and those I suspect came in from other vocabs that were subsumed by Schema.org - i.e., it certainly doesn't seem to be an 'accepted guideline' by Schema.org as a whole. I'm more than happy to continue this discussion though, as I'm certainly not convinced that I'm in either camp myself really (although I am leaning more towards 'not using' prefixes). Cheers, Pat. *Pat McBennett*, Technical Architect Contact | patm@inrupt.com Connect | WebID <http://pmcb55.inrupt.net/profile/card#me>, GitHub <https://github.com/pmcb55> Explore | www.inrupt.com On Mon, Mar 28, 2022 at 9:53 AM Rob Brennan <rob.brennan@adaptcentre.ie> wrote: > Hi > > I seem to recall at the meeting the issue was raised that some languages > do not have the upper/lower case characters we use in English/Western > languages and thus it is better to have the extra word to distinguish > property/class. > > rgds > rob > > On Sat, Mar 26, 2022 at 11:45 PM Harshvardhan J. Pandit <me@harshp.com> > wrote: > >> Hi. >> Turns out if you don't care about IE8 or earlier, HTML ids are >> case-sensitive. So I'll amend my answer as: just sem-web convention. >> AFAIK no one raised this as an question/issue before, so we continued >> using the same prefix-based notation in all properties. >> >> I went over the old minutes, and I couldn't find anything explicit about >> this. But I remember distinctly it being discussed and the room agreeing >> to use of prefixes as per sem-web convetion - probably during the 2018 >> workshop. >> >> If there's a call to change these (e.g. turn hasDataSubject into >> dataSubject) - this represents a major change because it will completely >> break any backward compatibility. However, we're not v1/stable, so this >> may not be that bad, but IMHO we should have a stronger reason than >> shaving a few bytes off. >> >> To give an idea of what others do: there's evidence for using both >> styles. With prefixes: PROV-O, TIME, ODRL ;; Without prefixes: DCAT, >> TIME (does both styles), SHACL. >> >> Regards, >> Harsh >> >> On 23/03/2022 19:46, Harshvardhan J. Pandit wrote: >> > Hi. I don't believe there is a formal record of this in the mailing >> list >> > or meeting notes (would like to be wrong on this), but the format was >> > because (a) sem-web convention; and (b) in case-agnostic environments, >> > DataSubject and datasubject cannot be distinguished and cause issues. >> > E.g. HTML ids are case insensitive and ReSpec (the documentation tool) >> > will annoyingly complain on duplicates between DataSubject and >> datasubject. >> > >> > On 23/03/2022 17:12, besteves@delicias.dia.fi.upm.es wrote: >> >> Hi everyone, >> >> >> >> Sorry if this topic has been discussed before and I missed it. >> >> >> >> Was there at any point a discussion about using "has" or "is" as >> >> prefixes for properties in DPV instead of starting a property with >> >> lowercase letters and a class with uppercase (e.g., instead of having >> >> dpv:hasDataSubject, having just dpv:dataSubject)? >> >> >> >> Best regards, >> >> >> >> Beatriz Esteves >> >> >> > >> >> -- >> --- >> Harshvardhan J. Pandit, Ph.D >> Research Fellow >> ADAPT Centre, Trinity College Dublin >> https://harshp.com/ >> >> >> -- >> * >> >> *Séanadh Ríomhphoist/Email Disclaimer* >> >> *Tá an ríomhphost seo agus aon >> chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus sin >> amháin é. Is féidir tuilleadh a léamh anseo. >> <https://sites.google.com/view/seanadh-riomhphoist>* >> >> *This e-mail and any >> files transmitted with it are confidential and are intended solely for >> use >> by the addressee. Read more here. >> <https://sites.google.com/view/dcu-email-disclaimer>* >> >> >> >> * >> >> -- >> >> <https://www.facebook.com/DCU/> <https://twitter.com/DCU> >> <https://www.linkedin.com/company/dublin-city-university> >> <https://www.instagram.com/dublincityuniversity/?hl=en> >> <https://www.youtube.com/user/DublinCityUniversity> >> > -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.
Received on Monday, 28 March 2022 14:15:00 UTC