W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > August 2018

Re: [dxwg] Provide guidance discouraging usage of blank nodes

From: makxdekkers via GitHub <sysbot+gh@w3.org>
Date: Fri, 24 Aug 2018 07:27:47 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-415676166-1535095666-sysbot+gh@w3.org>
In general, I agree that the use of blank nodes `should `be discouraged. 
However, it depends on whether or not there is an expectation that the object identified is something that should be linked to from other places or could be further described.
Of course, in the case of publishers and themes and locations and licences it's fairly obvious that blank nodes hinder linking and re-use, but there are cases where the use of a blank node might make sense. One of those is for the object of `dct:temporal`. In the European DCAT-AP, a period of time is defined with `schema:startDate` and `schema:endDate`, and in most cases it would not be useful to create a URI for a particular range of time. It needs to be noted that minting a URI implies a maintenance commitment -- a URI that is not maintained is worse than a blank node, in my opinion. 
Other than that, we can say whatever we want, but implementers will still do what works for them -- if they have legacy data that only contains text strings, they will very likely create blank nodes to carry the strings, because the only choice they have is mint a URI or use a blank node. In the future, given that, for example, DCMI plans to abandon `rdfs:range` for `schema:rangeIncludes`, it will be perfectly legal for those implementers to put the string, e.g. publisher's name, as a `rdfs:Literal` so the need for either minting URIs or creating blank nodes will go away.

-- 
GitHub Notification of comment by makxdekkers
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/300#issuecomment-415676166 using your GitHub account
Received on Friday, 24 August 2018 07:27:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:45 UTC