worked out this issue. According to my tests, the
reasoning works fine with blank nodes, but Protege and DL queries do not
*show* the results if they are blank nodes instead of URIs. Here is an
explanation:
http://dbooth.org/2015/fhir/bnodes/bnode-test.html
As a result of these successful
Hi Jeremy,
I worked with genomic data very similar to yours, and initially used
blank nodes for exactly the purpose that you describe below. However, I
regretted doing so when I realized that every time I loaded some of the
same source data, duplicate triples were added, because the system
On 4/3/13 4:07 PM, Michel Dumontier wrote:
The major motivation for avoiding blank nodes is that you cannot
reliably refer to those objects from outside the dataset. It precludes
any kind of linking or argumentation.
Yes, I know that re., Linked Data scenarios :-)
In Bio2RDF, we generate
The major motivation for avoiding blank nodes is that you cannot reliably
refer to those objects from outside the dataset. It precludes any kind of
linking or argumentation. In Bio2RDF, we generate URIs for all objects, and
use the identifier when provided, otherwise we generate one when there is
On 4/3/13 3:12 PM, Jeremy J Carroll wrote:
>There is, I think, a sustainable argument that blank nodes are not*necessary*.
I beg to differ. Blank nodes are absolutely necessary.
"Horses for courses" again.
Blank nodes are only problematic when misunderstood and used
inappr
One question that I didn't really answer today was about my choice to use blank
nodes extensively following
http://www.w3.org/TR/swbp-n-aryRelations/
[[
we did not give meaningful names to instances of properties or to the classes
used to represent instances of n-ary relations, but m
