Print

Print
There is a significant difference between applying RDF based data modelling, SPARQL, OWL, and other techniques in the privacy of your own enterprise data architecture, and the use of Linked Data principles to share information with others.

I would be well to remind ourselves in this thread of those four simple principles[1]:
  1. Use URIs for names of things.
  2. Use http URIs so people can look up those names.
  3. When someone looks up a URI, provide useful information using the standards (RDF)
  4. Include links to other URIs, so they can discover more things.

Principles 2, 3, 4 can be interpreted as encouraging you not to use blank nodes wherever possible.

I would suggest that the most powerful benefit of sharing data using these principles the the ability for both people and machines to use ‘follow your nose’ navigation across the relationships between described entities from many sources.  Much linked data is published via raw files without the need or use of Sparql or other data processing end-points.   

Making assumptions about the availability of OWL inferencing, and sparql queries to drive discovery places unnecessary burden on those that will want to implement systems, simply publish linked data, and simply consume it.

[1]http://www.w3.org/DesignIssues/LinkedData.html

~Richard

On 10 Jul 2014, at 19:57, [log in to unmask] <[log in to unmask]> wrote:

Whether this kind of idiom is acceptable RDF (I don't agree that it always is) it seems to me to be _terrible_ Linked Data. This is the opposite of allowing people to "follow their noses".

I think also that it is a little too blithe to rely on OWL inferencing to produce simple results from complex queries. OWL inferencing is fantastic technology but it is implemented very variously today. Some semantic frameworks have very full capabilities and some do not, and the extent to which their implementations are accessible of "tuning" vary as well. It doesn't seem at all to me like database tuning. It seems more like making assumptions on available SQL extensions. To be a little more specific about this, you could describe which OWL profile would be of interest and what kind of guarantees it could make around the extra time needed on the extension of a query.

---
A. Soroka
The University of Virginia Library

On Jul 9, 2014, at 10:20 PM, Stuart Yeates <[log in to unmask]> wrote:

On 07/10/2014 01:52 PM, Karen Coyle wrote:

I'm no expert in SPARQL, but I am going to presume that

http://www.example.com/books/book1
   a http://bibframe.org/vocab/Book .

Will result in more retrievals on queries for things of type
http://bibframe.org/vocab/Book

than

   _:bnode1 a bf:Instance ;
    bf:uri _:bnode2 .
 _:bnode2 a bf:Identifier ;
    bf:identifierValue "http://www.example.com/books/book1" .

In other words, the further down you bury the key information (the URI
for the thing) the less likely your data will be discovered and linked.

My understanding is that if there is OWL logic available to the query engine that can be used to confirm these queries are the same, SPARQL should always return the same results for the two queries.

There are, of course, questions of efficiency, but these are not essentially different to the current issues many of us face with tuning database queries for reports we run on our ILS's.

cheers
stuart