Re: AW: [Dbpedia-discussion] Fwd: Your message to Dbpedia-discussion awaits moderator approval

Hugh Glaser wrote:
> Hi Kingsley.
>
> On 12/08/2009 20:07, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>
>   
>> Peter Ansell wrote:
>>     
>>> 2009/8/12 Hugh Glaser <hg@ecs.soton.ac.uk>:
>>>  
>>>       
>>>> Are you saying that the only way to access Linked Data is via SPARQL?
>>>>    
>>>>         
>>> That is going a bit far, but in the end if you want to allow people to
>>> extend the model it has to be done using SPARQL. If the extension is
>>> taken well by users then it could be included in what is resolved for
>>> the URI but that doesn't mean it is not Linked Data up until the point
>>> it is included.
>>>
>>> I for one loved the recent addition of the Page Links set in a
>>> separate Named Graph, and I don't see how this is different.
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>>
>>>  
>>>       
>> Amen!  :-)
>>
>> Hugh: the important point is this: the person that deems a piece of data
>> to be fit for sharing on the Web can mint a  HTTP URIs for said data,
>> even it this happens from afar e.g. via Pubby or Virtuoso's Linked Data
>> Deployment services against remote SPARQL endpoints. Of course, the same
>> thing can happen via RDFizers that produce proxy/wrapper URIs from a
>> variety of data sources. None of this breaks the principles behind  the
>> Linked Data meme :-)
>>     
> I agree with all that - it is a description of what I have been saying.
> We clearly have a strong agreement here.
>
> On the other hand:
> Thus SPARQL is not a required part of the Linked Data meme. Also if Named
> Graphs are not visible without using SPARQL, Named Graphs are not a good
> solution to problems in the Linked Data meme.
>   
Of course they are. You have to partition data for a myriad of reasons. 
You just can put it all in one real or virtual bucket. You must 
partition or you are on a high speed boat to data maintenance hell, and 
that's just one of the problems.
> This will become a more significant issue with the forthcoming explosion of
> Linked Data from governments such as the UK, where the data provider will
> not be offering a SPARQL endpoint.
>   
Nice example, assuming you are implying that each of the data items will 
have HTTP URIs but no SPARQL endpoints.  If so, what stops me making a 
set of statements about the published data in my own Web accessible 
Linked Data Space (which is partitioned using Named Graphs)  using my 
own HTTP URIs ?  You can simply like of dislike the data exposed by my 
URIs, that's it re. the broader Web.

btw - in my world view, SPARQL is an implementation detail re. Linked 
Data meme. I've even been tapped (by Juan Sequeda) saying that :-)
> Telling them to put their co-ref data in a Named Graph is just not an
> option.
>   
In their particular case, here is the very important point to note. They 
are the original data publishers. Thus, I am not expecting them to move 
any "owl:sameAs" or "owl:equivalentClass" style assertions into a 
separate graph per se. What I am saying is this: If you, I, or anyone 
else decides to construct a set of co-reference style statements about 
the UK data, best we do it in our own Linked Data spaces.

Now zipping back to the DBpedia example:
We have multiple parties contributing Linked Data to the project, many 
are outside the original trinity of: ASKW, Freie, and OpenLink. Thus, in 
situations like this it's preferable to put the contributed datasets in 
their own Named Graphs albeit within a single Virtuoso instance. It also 
means that even if the contributed datasets are pseudo hot-staged in 
their own Named Graphs, anyone can use still tools like Pubby or 
Virtuoso's Linked Data Deployment services to mint HTTP URIs in their 
own Linked Data Spaces via the DBpedia SPARQL endpoint.

I note that the UK example reveals where we have crossing wires a little 
:-)
> Best
> Hugh
>
>
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Wednesday, 12 August 2009 20:11:22 UTC