W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: Re : Option 8

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 19 Aug 2009 20:30:33 +0100
Message-ID: <4A8C52D9.3020000@deri.org>
To: Gregory Williams <greg@evilfunhouse.com>
CC: public-rdf-dawg@w3.org
Gregory Williams wrote:
>
> On Aug 19, 2009, at 6:37 AM, Axel Polleres wrote:
>
> > > If the service description if fetched from the exact endpoint URI, 
> > and
> > > the description looks like:
> > >
> > > <> a sparql:Endpoint ;
> > >    sparql:has sparql:featureA ;
> > >    ...
> >
> > If I understood correctly, the URI identifying the endpoint does not 
> > necessarily need to be the URL of the endpoint, ie. cf. [1]
> >
> > Greg suggests in [1] the vocabulary providing a separate predicate
> >
> >  sd:url
> >
> > to point to the actual URL (in the case of your example probably the 
> > public one https://machine.example.com/myapp/sparql/), so is that 
> > really an issue?
> >
> > In other words, would the relative URL be really needed?
>
> I don't think this is something we've talked about much, but I did 
> that for two reasons:
>
> 1) Using sd:url is how DARQ did it, so there was an existing term to 
> use.
>
> 2) I used a blank node for the service because coining an arbitrary 
> URI seemed strange, but the access URL (where you get the service 
> description, or an html form, or something else) clearly isn't the 
> same resource as the service.
>
In which case

 sd:url rdfs:domain sd:Endpoint.
 sd:url a owl:InverseFunctionalProperty.

may make sense, yes?

Axel

> .greg
>


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Wednesday, 19 August 2009 19:31:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT