RE: requirement: rdfs query (for lack of a better name...)

>  > Where in my requirement does it say "just a little bit of inference"?
>>  Where does it imply it? I must have missed that bit. :>
>>
>>  And, besides, charter thwack:
>>
>>    1.8 Derived Graphs
>>
>>    The working group must recognize that RDF graphs are often
>>    constructed by aggregation from multiple sources and through logical
>>    inference, and that sometimes the graphs are never
>>    materialized. Such graphs may be arbitrarily large or infinite.
>
>We've been through this before, and I'm getting a bit tired of it.
>This sentence seems to be pointing out exactly what I've been saying: we
>can't standardize an implementation because implementations will have
>very different requirements depending on how they get their knowledge
>about the underlying data model.
>This paragraph even seems to make explicit that we're meant to be
>addressing how we query a graph, not some of the particular ways to form
>that graph from.
>If you've got some RDF and some RDFS, then there are two quite
>reasonable graphs: the raw RDF the way it's written, and a "completed"
>graph which has a whole bunch of inferred triples.

Right, exactly. In fact there are quite a number of these.

>(There are also a
>number of other graphs which can be derived from this data set in other
>ways, such as the possible graphs, the impossible graphs, the graphs
>with the directions of all edges reversed, the interesections or unions
>of any of these other graphs, etc.)

Yes, but lets keep things in perspective. How about only considering 
valid derivations from the basic graph, and maybe even requiring a 
closure relative to some subset of the complete set of rdfs rules: 
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#RDFSRules

>An implementation should have the freedom to interpret a query against
>any of these "virtual" graphs, thus we cannot specify how an
>implementation operates.

No, but what we could consider is ways for the query to indicate 
which virtual graph it is intended to be aimed at. A server might 
just keep one base graph but treat the query differently if it 
indicates it is aimed at the closure under transitivity of 
rdfs:subClassOf, for example (rules rdfs6 and rdfs9).

>
>>  > What's more, adding support for just one particular flavor of
>>  > supplementary semantic knowledge (RDFS) is great way to
>>  kill off use of
>>  > any other knowledge sources.
>>
>>  Uh... RDFS is hardly "one particular flavor of supplementary semantic
>>  knowledge". That's about as perverse a description as I can
>>  imagine. Besides, if you're worried about "killing off" OWL, that's an
>>  argument to do RDFS in 1.0 and OWL in 2.0, not an argument not to do
>>  RDFS at all.
>
>I think it's quite clear that sucking every possible type of querying
>into our specification is about the worst way to write a standard
>possible.
>The fact that inferencing is very useful is an excellent reason to make
>sure our query language is compatible with use where RDF is the data
>model on which inferencing occurs.
>The fact the inferencing is a complex and open-ended problems and that
>we could not possibly address it (because the basic semantic encodings
>are still being standardized) is a pretty incontrovertable argument that
>we can't solve the inferencing problem. I think that's a good reason not
>to try.

Well, up to RDFS at least there is a complete set of rules which are 
pretty transparently related to the formal semantics, if we want to 
use them.

>
>Let's leave derived graphs and inferencing to working groups that know
>how to address them and confine ourselves to representing queries
>against the data model which underlies it all.

Im sympathetic to this pov, however.

Pat



-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes