RE: URIQA questions

> -----Original Message-----
> From: ext Benja Fallenstein [mailto:b.fallenstein@gmx.de]
> Sent: 08 July, 2003 17:07
> To: Stickler Patrick (NMP/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: 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.

It may be a matter of what information is explicit
versus implicit.

IMO a URI occurring as the predicate or object of an RDF
statement does of course have implicit in it information
about that resource as it relates to the subject and/or
statement, but is not IMO explicit information about
that resource.

Explicit information about a resource is, IMO, expressed
by those statements in which the URI denoting the resource
occurs as the subject.

Concise bounded descriptions, then, provide explicit
knowledge about a particular resource (along with
auxilliary knowledge that cannot be accessed directly,
such as statements about anonymous nodes occuring
in explicit statements about the resource and all
reification statements of the above).


> > 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 I'd agree, insofar as implicit information is concerned.

> > 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.

Hmmm.... well, there are two key facets to the URIQA model,
(1) concise bounded descriptions, and (2) a means to obtain
concise bounded descriptions via the URI alone.

I consider (1) to be more important/central to (2) though
both are essential parts of the model.

The machinery for (2) is a secondary issue, and constrained by
practical and political issues.

So, from my viewpoint, the definition of the concise bounded
description *is* the model, not defined in terms of the model.

> [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?

They would potentially be partially authoritative. Meaning
that any statement having a subject for which the server
in question is the authoritative server, that statement
could be considered authoritative.

I.e., insofar as any graph returned in response to
a general query intersects with a potential concise
bounded description that that same server might
provide, that intersection is authoritative.

But the URIQA model does not and will not specify such
matters as they relate to more general query models.
That should be specified for any more general model
which includes the URIQA model as a subset.

> >>> 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 :)

If you continued to use urn: URIs, yes. But my suggestion
was to use HTTP-URNs, and my proposal provides for a regular
mapping from urn: URIs to HTTP-URNs:

   urn:X:Y -> http://X.D/Y

where D is the root domain corresponding to 'urn:'

So, presuming the managing authority for urn-5 provided a
PURL or PURL-like mapping service hosted at http://urn-5.D,
sw agents would then be able to automap any urn:urn-5:
URIs (and generally, any urn: URI whatsoever) to their 
corresponding HTTP-URNs and thereby obtain
authoritative descriptions of the denoted resources.

> >>> 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).

I look forward to that day.

But I don't think it will be any day very soon. Folks are
working on just such a standardized API, but it will take
time to harmonize all the requirements and constraints and
(if even possible) come up with a generalized model that
is sufficiently broad in its utility to serve as a solid
foundation for such a globally ubiquitous query API.

In the meantime, URIQA can be deployed now, with very minimal
effort, and provides the lion's share of functionality needed
by SW agents.

Further work on a more general, powerful query API, can
then augment the URIQA model.

Crawl, walk, run...

Better to be able to crawl, or even walk, about the semantic
web already now with URIQA than to do nothing but wait until 
one can run about the semantic web with a more encompassing 
query API. But even when crawling/walking about the SW with
URIQA, one can look forward to running in the future, and
adoption/deployment of URIQA will not defer or slow work on
that future API, but will IMO accelerate work and adoption,
as the power and utility of the SW will be proven by URIQA.

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

Never said it did (and/or certainly didn't mean to imply so).

> > 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.

Again, crawl, walk, run. It will be several years, I think,
until we see any broad adoption of a standardized query API
for RDF encoded knowledge. I look forward to that milestone
with great anticipation, and will be doing my best to
contribute to its realization. In the meantime (and still thereafter,
since we can expect such a general API to subsume URIQA) we
can implement the foundation of the semantic web with URIQA.

Cheers,

Patrick

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

Received on Wednesday, 9 July 2003 04:15:35 UTC