Re: Service or graph store naming.

On 2011-03-01, at 09:13, Andy Seaborne wrote:
> 
> On 01/03/11 05:25, Gregory Williams wrote:
>> On Feb 15, 2011, at 11:37 AM, Andy Seaborne wrote:
>> 
>>> On 15/02/11 16:31, Gregory Williams wrote:
>>>> On Feb 15, 2011, at 3:17 AM, Andy Seaborne wrote:
>>>> 
>>>>>> • The RDF content returned from dereferencing a service
>>>>>> URL<U> must include one triple matching: ?service sd:url<U>
>>>>>> .
>>>>> 
>>>>> I don't think that is necessary.  It is desirable for simple
>>>>> processing of the RDF but MUST is far too strong.  After all
>>>>> the service may have different names (over time, your name, my
>>>>> name, bnode now, name later) - this is the semantic web and
>>>>> there is not usually a unique name assumption.
>>>> 
>>>> Understood. Would you be happy with a "SHOULD"? I'm OK with
>>>> "bnode now, name later." What I'm worried about is "bnode now,
>>>> name also now" -- I don't want to make it more difficult for
>>>> clients trying to use service descriptions by requiring support
>>>> for IFPs (or complex queries trying to work around the lack of
>>>> support for IFPs).
>>> 
>>> SHOULD is acceptable - personally, I'd make it more of a
>>> style-of-RDF comment.
>> 
>> Andy,
>> 
>> Having discussed the conformance issue some more with Lee and Sandro,
>> I think I'm more comfortable including some normative text. Rereading
>> this thread, I'm wondering why you think the MUST language is too
>> strong here. At one point I had text that said "MUST include one and
>> only one triple matching", but I don't think the text above ("MUST
>> include one triple matching") runs afoul of your concern about unique
>> names. What do you think?
>> 
>> thanks, .greg
> 
> It seems to me that mandating one discovery mechanism is a separate issue from service description.  Highlighting and suggesting ways is good - we expect GET <service> to return a description.  But there are other possible ways to discover service information, for example, a repository that is a collection of services descriptions all in one graph (this is RDF - merging information is OK).
> 
> If I add a triple
> 
>  <newName> sd:URL <http://www.example/sparql/> .
> 
> it is odd to me that a formally legal service description document
> becomes a non-document.  Hence the "SHOULD" language suggesting helpful
> practice but recognizing it is not a necessity.
> 
> Similarly, if I merge two separate service descriptions about two different, unconnected services, it seems reasonable to think of as still a service description of each.
> 
> 
> Not that I'm intending to reuse the same machinery but experience with a similar framework, Jena assembler files, do this - there is no reason why multiple descriptions of things can't be in the same file.  It is easier and more convenient to, say, have one dataset description per file because the common use case is needing one dataset description, but in another less usual case (a Joseki server config file) it makes sense in that case to have several dataset descriptions in one file.

Agreed. LV2 (an RDF-heavy standard for DSP software modules) allows descriptions of one or more modules in each manifest file - it's convenient to include multiple descriptions in one file sometimes.

- 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, 1 March 2011 11:55:20 UTC