- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 8 Feb 2011 23:27:57 +0000
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: Chimezie Ogbuji <chimezie@gmail.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 2011-02-08, at 22:28, Gregory Williams wrote:
...
>>> Can we have multiple service descriptions (query, update,
>>> RESTDatasetService) in one description? If so, which URL gets that
>>> description?
>>
>> I wouldn't think so. I've assumed that each service description
>> document has only one sd:Service instance and
>
> I think multiple service descriptions in one SD document would be perfectly fine. For example, having two endpoint urls /query and /update that use the same underlying service (with one accepting queries, the other updates), and both return the same document with two service descriptions (but perhaps a shared dataset description).
Agreed, I'd like to do this in 4store, e.g. so OPTIONS on / (which exposes no services itself) can advertise /sparql/, /update/ and /data/.
>> (incorporating what
>> Gregg said about the way the sd:url property is used), the service URL
>> is
>>
>> SELECT ?SERVICE
>> {
>> { ?SERVICE a sd:Service FILTER(isUri(?URL)) } UNION { ?ALIAS sd:url ?SERVICE }
>> }
>
> This is a misunderstanding. In my last email I tried to make clear that what's in the document right now was a regression from what was intended. The intention was only { [] sd:url ?SERVICE }, but I'm starting to think the original motivation for that isn't actually that great, and we might want to change it to just { ?SERVICE a sd:Service } (and maybe drop sd:url). I think having both would be confusing and not provide that much benefit. Thoughts on this?
Yes, I'd rather see only one way of providing the URI, I don't really care which one.
- Steve
--
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203 http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 8 February 2011 23:28:36 UTC