Hugh Glaser wrote:
Good stuff.
However, I don't think that Named Graphs are the answer.
I get my Linked Data by resolving URIs over http.
If I ask your Linked Data Space (I hope that is the right use of your
terminology) for something like
curl -H "Accept: application/rdf+xml" http://dbpedia.org/resource/London
and follow the redirect don't I still get the non-wikipedia data with the
wikipedia data?
Or am I not understanding something?
The link chain shouldn't be broken. Named Graphs should have zero impact
on HTTP URIs.
I think Alan is saying: put what is best described as a linkbase dump in
a separate Named Graph. Doing this shouldn't break the tapestry inherent
in the HTTP URIs (the data conductors). We have tons of data in
<http://lod.openlinksw.com> partitioned across named graphs, and none of
that breaks the "follow-your-nose" pattern. Remember, I am a stickler
for keeping the HTTP URIs of entities in full scope of user agents :-)
The only time you might have an issue is when performing SPARQL, where
explicitly identifying the Named Graph in the FROM Clause may aid
performance (and even here this depends on the indexing in placece re,
the RDF DBMS insta, these days re. Virtuoso that doesn't even matter
since the default indexing scheme has been changed).
Kingsley
Best
Hugh
On 28/07/2009 11:17, "Kingsley Idehen" <[email protected]> wrote:
Hugh Glaser wrote:
For the record ( © Alan!).
I consider it bad practice to keep the knowledge about linking in the same KB
as the substantive knowledge you are representing.
You need two KBs: one for the knowledge you are publishing, and one for the
linkage you are working on.
These have very different provenance, maintenance patterns, etc..
And you can include a link from URIs that you generate to the linkage KB.
For terminology consolidation purposes, what you call a KB is a
"Linked Data Space" in my parlance :-)
Yes, the partitioning suggested above is very important. Thus, you need
purpose specific Linked Data Spaces (hosing many Named Graphs) if you
seek to make things a little clearer to data consumers and their agents.
In fact, this would then help Alan's problem about sameAs:- he could simply
decide not to get your view of the linkage, whereas with sameAs in the
resources he has no choice but to accept your view, and even your predicate
when he resolves a URI or queries the SPARQL.
And I do agree with you about minting URIs to your local stuff, including
authors; it is error-prone to try to re-use things like dbpedia for this, on
any scale. And this is why you need to tackle the linkage problem as a separate
engineering activity.
Best
Hugh
(Of course I do have some software and architecture that supports separate
linkage KBs (our CRS) so I would say this, but nevertheless I think it is the
correct engineering approach, however it is done. Separation of Concerns.)
Note, we've partitioned DBpedia in such a way that you now have a Graph
IRI for each data set within this particular Linked Data Space.
Kingsley
On 28/07/2009 02:23, "Eric Lease Morgan" <[email protected]> wrote:
On Jul 25, 2009, at 5:09 AM, Bill Roberts wrote:
Regarding linking to external resources, what it seems you want
to do is to identify the dc:creator of the book, hence say that
the creator is the person whose name was Thomas More. You could
create your own URI and if you are managing a whole bunch of data
about books and authors, then there could be reasons to do that,
but in general if there is a satisfactory existing URI, it is
preferable to use it. Dbpedia seems to have become the de facto
standard...
Okay, then how's this for a recipe to create rich linked data of
electronic books and authors within my own site as well as to the
outside world:
1. Mint URIs pointing to representations of local etexts
2. Mint URIs pointing to representations of authors of local etexts
3. In resources of etexts, include owl:sameAs links to DBpedia
resources
4. In resources of etexts, point to local URIs of authors
5. In resources of authors, include owl:sameAs links to DBpedia
resources
6. In resources of authors, include owl:creatorOf links to local
etexts
7. For extra credit, do the same thing for subjects/keywords
For example, the following resource descriptions:
<!-- etext #1; points to local author and remote title -->
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:dcterms="http://purl.org/dc/terms/";
xmlns:owl="http://www.w3.org/2002/07/owl#";>
<rdf:Description
rdf:about="http://infomotions.com/etexts/id/more-utopia-221";
owl:sameAs="http://dbpedia.org/resource/Utopia_(book)">
<dcterms:title>Utopia</dcterms:title>
<dcterms:creator
rdf:resource="http://infomotions.com/etexts/authors/resource/thomas-more
" />
</rdf:Description>
</rdf:RDF>
<!-- etext #2; points to local author and remote title -->
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:dcterms="http://purl.org/dc/terms/";
xmlns:owl="http://www.w3.org/2002/07/owl#";>
<rdf:Description
rdf:about="http://infomotions.com/etexts/id/more-reality-404";
owl:sameAs="http://dbpedia.org/resource/Reality_(book)">
<dcterms:title>Reality</dcterms:title>
<dcterms:creator
rdf:resource="http://infomotions.com/etexts/authors/resource/thomas-more
" />
</rdf:Description>
</rdf:RDF>
<!-- author; points to local etexts and remote author -->
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:owl="http://www.w3.org/2002/07/owl#";>
<rdf:Description
rdf:about="http://infomotions.com/etexts/authors/resource/thomas-more
"
owl:sameAs="http://dbpedia.org/resource/Thomas_More";>
<owl:creatorOf
rdf:resource="http://infomotions.com/etexts/id/more-utopia-221
"/>
<owl:creatorOf
rdf:resource="http://infomotions.com/etexts/id/more-reality-404
" />
</rdf:Description>
</rdf:RDF>
--
Eric Lease Morgan
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
