Re: URIQA questions

Hi Patrick!

Patrick.Stickler@nokia.com wrote:
>>Ok. So URIQA makes the following design decisions:
>>
>>- It does not provide all authoritative information about a resource; 
>>instead, it provides an somewhat arbitrary, but well-defined 
>>subset that 
>>is judged to be reasonable in many cases.
> 
> I think we disagree in what "about a resource" means.

So you define "information about a resource" to be (only) "the concise 
bounded description of a resource"? Indeed I wouldn't agree with that, 
but that's only a matter of terminology, of course.

> No, it does not provide all triples in which the resource
> participates, only where the resource is the subject.

(I wouldn't say that "all triples in which the resource participates" is 
"all information about the resource"-- I'd say that's only a subset of 
the information about the resource-- but again, that's just terms.)

> And the selection of what is provided in a concise bounded
> description is hardly arbitrary. 

I didn't mean that there is no rationale behind this choice. I meant 
arbitrary in that the rationale doesn't follow from the model-- it 
follows from how that model is expected to be used.

[from other mail]
> However, if the authoritative server for ex:Foo also provides
> a general query interface, it may also both maintain and
> can provide information about fy:Bar in general queries.
> Those general query results, however, would not be authoritative
> concise bounded descriptions.

They would not be any kind of concise bounded descriptions, naturally. :-)

For clarification: would you argue that they aren't authoritative, eithher?

>>> Worse, if you have
>>> 
>>>      ex:Foo   rdfs:subClassOf   
>>> <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>
>>>      <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>  ont:warning  
>>> "Hazardrous!"
>>> 
>>> there is no way to get the latter triple, even if it is what 
>>> the person 
>>> who minted the URN thought, since there is no authority for 
>>> urn-5 URIs.
> 
> Which is precisely what has motivated me to propose an
> alternative way to accomplish the goals of URNs. C.f. 
> 
> http://lists.w3.org/Archives/Public/uri/2003Jul/0005.html
> 
> Using HTTP-URNs as thus defined (aka PURLs) rather than urn: URIs
> would allow you to derive the fullest benefit from not only URIQA
> but the general web architecture already globally deployed.

Wouldn't make a difference since there is no authority for urn-5. URIQA 
still stays a hammer, and my data a screw :)

>>> I happen to use this, so URIQA really doesn't work for my data.
> 
> Understood. URIQA is an extension to the Web in order to
> enable the Semantic Web. In both cases, HTTP is a foundational
> technology. URI schemes that are not meaningful to HTTP are
> ill suited not only for the Web, but also for the Semantic Web.

Now, *suppose* that there would be a general query API supported by all 
HTTP servers on the Semantic Web. I mean, there could be, it's not 
prevented by the RDF specs. Then, my data wouldn't present any problem 
to the Semantic Web (any more than bnodes do, you cannot get 
authoritative information about them either).

So, I rather think it's not the Semantic Web in general that has 
problems with my data.

> URIQA is intended to provide a simple but powerful core
> of functionality that will be deployed on every SW server
> on the planet (and perhaps beyond).
> 
> As such, it cannot, and should not, try to address every 
> possible (or even common) scenario.

Hm. I do hope that there will ultimately be an agreed-upon protocol that 
allows us to query, from a knowledge base, all triples that any resource 
participates in. Maybe you're right and that's unrealistic, but I hope not.

- Benja

Received on Tuesday, 8 July 2003 10:08:38 UTC