Re: Using Linking Open Data datasets

Hello!


>
> Please note as well that we could learn something from 'Protocol for Web
> Description Resources' (POWDER) [3] (I've cc'd the WG now). When we've
> gathered some more requirements and know more precisely what we want to
> express with it and what is out of scope, we might be able to come up
> with a concrete proposal.
>


Actually, it may be slightly off-topic, but I would really need
something able to describe the actual "content" of a SPARQL end-point
or a RDF document. We talked a bit about that on #swig some time ago,
and we came across http://esw.w3.org/topic/SparqlEndpointDescription
and http://esw.w3.org/topic/SparqlEndpointDescription2.

Ultimately, what I would need is a *really* simple vocabulary to
express "this document or end-point holds the following information".
So I would need something like:

:SPARQLEndPoint a owl:Class.
:RDFDocument a owl:Class.
:holds a owl:DatatypeProperty. # associates a rdf doc or a sparql end
point to a sparql ASK query. (I think there is a datatype for
something like that, if I remember a talk about networked graphs [1]
at WWW right).


To be able to state things like:

<https://example.org/rdfdoc> a :RDFDocument; :holds "ASK
{<http://moustaki.org/foaf.rdf#moustaki> foaf:based_near ?loc}".
<http://example.org/sparql> a :SPARQLEndPoint; :holds "ASK
{<http://moustaki.org/foaf.rdf#moustaki> :phone_number ?num"; :holds
"ASK {?people foaf:knows ?x. ?x foaf:knows
<http://moustaki.org/foaf.rdf#moustaki>}".

(this sort of things may be much cleaner in full N3.)

The first one describes a RDF document holding information about my
current location (in my case, I want to put that in a  RDF file with
limited access). The second one describes an end-point holding phone
numbers for me, as well as information about people that know people
that know me (I just made that up, perhaps not the best example :-) ).

Cheers!
y


[1] http://isweb.uni-koblenz.de/Research/NetworkedGraphs

> Good to see things moving on!
>
> Cheers,
>        Michael
>
> [1] http://sw.deri.org/2007/07/sitemapextension/
> [2] http://community.linkeddata.org/MediaWiki/index.php?MetaLOD
> [3] http://www.w3.org/TR/powder-use-cases/
>
> ----------------------------------------------------------
>  Michael Hausenblas, MSc.
>  Institute of Information Systems & Information Management
>  JOANNEUM RESEARCH Forschungsgesellschaft mbH
>
>  http://www.joanneum.at/iis/
> ----------------------------------------------------------
>
>>-----Original Message-----
>>From: Jun Zhao [mailto:jun.zhao@zoo.ox.ac.uk]
>>Sent: Thursday, May 29, 2008 7:22 PM
>>To: Hausenblas, Michael
>>Cc: public-lod@w3.org
>>Subject: Re: Using Linking Open Data datasets
>>
>>Hello Michael,
>>
>>
>>Hausenblas, Michael wrote:
>>> Dear LODers,
>>>
>>> One thing we encounter recurrently when using the LOD datasets is
> where
>>> to 'start best'. I'm unsure how to handle this situation, so I tried
> to
>>> gather some issues along with a simple proposal how to deal with it
>>> (called MetaLOD) at [1]. The idea basically is to develop a
> vocabulary
>>> and gather information 'about' the LOD datasets, such as 'at Geonames
>>> you get location-based information', etc.
>>>
>>This looks very interesting. And I desperately share your needs, i.e.
>>looking for the data to link to.
>>
>>I am also thinking about rdfs:seeAlso, and something like skos:related,
>
>>skos:broader or skos:narrower.
>>
>>A snip showing how I could use your structure to describe our data:
>>
>>:LODataset a rdfs:Class ;
>>            rdfs:label "a LOD dataset" .
>>
>> set:DBpedia a :LODataset ;
>>             owl:sameAs <http://dbpedia.org/> .
>>
>> set:Geonames a :LODataset ;
>>              owl:sameAs <http://sws.geonames.org/> ;
>>              foaf:topic
>><http://dbpedia.org/resource/Location_%28geography%29> .
>>
>> set:flyted a :LODataset ;
>>              owl:sameAs <http://www.fly-ted.org/sparql> ;
>>              foaf:topic <http://dbpedia.org/resource/Biology> ;
>>              foaf:topic <http://dbpedia.org/resource/Drosophila> ;
>>             foaf:topic <http://dbpedia.org/resource/Image> ;
>>              rdfs:seeAlso <http://spade.lbl.gov:2021/> ;
>>              skos;related <http://spade.lbl.gov:2021/> ;
>>              skos:narrower <http://dbpedia.org/> .
>>
>>
>>What do you think?
>>
>>All the best,
>>
>>Jun
>>
>>> I'm aware of the fact that each LOD dataset *should* provide this
> kind
>>> of information about itself, however (i) not all do AFAIK, and (ii)
> even
>>> if all did, how can an application determine effectively and
> efficiently
>>> which LOD dataset might be good to use for a certain task? I don't
> want
>>> to propose a 'centrally controlled registry' with this idea, just a
> way
>>> to flag what to expect from a LOD dataset as a kind of jump start.
>>>
>>> A formal description of the LOD dataset would also be beneficial for
>>> other exploration purposes, I guess. For example we could express
> access
>>> options for a LOD dataset (dump, SPARQL endpoint, etc.) or QoS
>>> information, even trust issues or (user) ratings might be of
> interest.
>>>
>>> Any thoughts?
>>>
>>> While I'm here: In case you're around at ESWC08, come and join us at
> the
>>> LOD gathering [2]
>>>
>>> Cheers,
>>>      Michael
>>>
>>> [1] http://community.linkeddata.org/MediaWiki/index.php?MetaLOD
>>> [2]
> http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenD
> ata/TenerifeGathering
>>>
>>> ----------------------------------------------------------
>>>  Michael Hausenblas, MSc.
>>>  Institute of Information Systems & Information Management
>>>  JOANNEUM RESEARCH Forschungsgesellschaft mbH
>>>  Steyrergasse 17, A-8010 Graz, AUSTRIA
>>>
>>>  <office>
>>>    phone: +43-316-876-1193 (fax:-1191)
>>>   mobile: +43-699-1876-1165
>>>   e-mail: michael.hausenblas@joanneum.at
>>>    skype: mhausenblas
>>>      web: http://www.joanneum.at/iis/
>>>
>>>  <see also>
>>>           http://sw-app.org/about.html
>>>           http://riese.joanneum.at
>>> ----------------------------------------------------------
>
>

Received on Friday, 30 May 2008 09:54:47 UTC