Re: Starting the document

On Mar 15, 2004, at 14:31, ext Jeremy Carroll wrote:

>
> This is an editorial problem, I will try and make the text clearer:
>
>>
>> "It is not possible to use ... a URIref which is not a URL [as the  
>> name
>> of a graph]".
>
> This is only meant to refer to serializing named graphs by using  
> RDF/XML on
> the web ... with the convention that the name is the retrieval URL - it
> can't be an arbitrary URI because there is no retrieval algorithm - it  
> is
> not meant to prevent graph names being blank nodes.

OK. Sorry. I thought you making a more fundamental claim. Nevermind ;-)

>
>
>>
>> I don't see the necessity for this constraint. The distinction between
>> a URI and URL is one of perspective and application. A URI which may  
>> not
>> today resolve to any representations may do so tomorrow. Hence, what  
>> is
>> or is not a URL should have no affect on the suitability of any URI to
>> name a graph.
>>
>> I'm also not (yet) convinced that a blank node can't denote a graph,
>> but I'm OK with saying that it can't, since explicit URIs will have
>> IMO important significance in the signing/authentication process.
>>
>> --
>>
>> Can we use the term URI and avoid the use of the term URL entirely?
>> (which is, in any case, considered a best practice to do so)
>>
>
> I try to use URL when I am specifical meaning a URI with a built-in  
> GET,
> which I think is OK? (Perhaps you could educate me - briefly)

Well, OK. I guess that is fair enough usage of the term URL. I guess
I've been thinking so much lately about architectural rather than
application issues that I'm oversensitized to certain terms...

It might be cleaner (at least to me) to use the term URI but state
that we are primarily concerned here with URIs which are resolvable
to RDF/XML representations (commonly known as URLs),
and then use the term URI throughout to be more in line
with the latest practices recommended by the TAG/REST/IETF/etc
where URL is deemed antiquated and for the most part deprecated.

Especially since much of the functionality has nothing to do with
how one obtains the graph -- i.e. whether one got it by dereferencing
the URI denoting it, or by some other means.

But I don't intend to be pedantic about it...

>
>
>> --
>>
>> We could add a subsection in section 6 to explicitly address
>> termination of assertion/trust chains via some extra-RDF
>> bootstrapping mechanism, whether we introduce one or not.
>>
>
> We certainly need to address the termination of the bootstrap ... I am  
> going
> to try and pick things off the thread.


Sorry for all the debris. Hopefully it won't be too hard to see
the good bits...

>
>> --
>>
>> Do we want to cover the query language, or address that in some
>> separate/future paper -- i.e. is the query language needed in order
>> to describe/demonstrate the key points of the paper?
>>
>>
>
> Chris's earlier document
>
> http://lists.w3.org/Archives/Public/www-archive/2004Feb/att-0072/swig- 
> bizer-
> carroll
>
> seemed to me to introduce the query language in about 1 paragraph + 1
> example, and then save that space over by using the query language in  
> the
> later examples. I don't think we should overcommit to it - e.g.  
> indicate it
> as only for the examples and motivate it as a minor extension to RDQL.
>
> I certainly don't think we have enough space to do anything more on  
> query,
> and it is not crucial, but I felt that swig-bizer-carroll flowed better
> because of this part.

OK. No problem. I wasn't sure if we were talking 2 paras or 2 pages.
I agree that having something akin to the above referenced post
sounds reasonble and useful.

(though there is always the risk of having too many targets in one
paper for reviewers to aim at... and some folks take query rather
passionately ;-)

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 15 March 2004 07:53:03 UTC