RE: LANG: Moving issues 5.6 and 5.14 forward

> -----Original Message-----
> From: heflin@EECS.Lehigh.EDU [mailto:heflin@EECS.Lehigh.EDU]On Behalf Of Jeff Heflin
> Sent: Tuesday, September 24, 2002 9:50 PM
> To: Massimo Marchiori
> Cc: WebOnt
> Subject: Re: LANG: Moving issues 5.6 and 5.14 forward
>
>
> Massimo Marchiori wrote:
> >
> > The point is that in order to find a solution, we need (well, it would be better, say) to know better what the meaning of
imports
> > and versioning are.
> > At high-level, there are two choices, as been discussed, to include these things:
> > + put the thing "in RDF"
> > + put the thing "outside RDF"
> > These don't come for free, on either sides. Since we're on it, the "outside RDF" has as major impact the fact that, as we're
using
> > RDF as exchange syntax, the "thing" cannot be exchanged, and it's bound to its local instantiation.
> > Now, don't get me wrong, two weeks ago on the call I've advocated heavily, with Peter, against the dangers of putting things "in
> > RDF", so I'm not saying the other spectrum is the one to choose too, just pointing out the implications.
> > So, back to the issue, putting things "out", while nicely avoiding some RDF troubles, has some drawbacks too. Whether
> these are real
> > drawbacks or not, depends on the meaning of the "thing", so I don't think we can easily choose one or the other (or similar
> > variations) before we have clear what we need the "thing" to be.
>
> Massimo, I've given intuitive definitions of these things, and we've
> seen some proposals for formal definitions, even a use case for
> versioning. Furthermore, the requirements document quite clearly points
> out the need for both imports and versioning. I chose to attack the
> domain of discourse problem because a) it seems like were closer to an
> agreement on that than on "how we define imports" and b) we must answer
> to the domain of discourse question before we can come up with a precise
> definition of imports.

I was expanding on [1]'s:
  If we can get agreement on this, then I think we can start tackling the
  issue of how do we define the meaning of imports.
which implied we don't seem to have yet a clear def for the issue at stake.
Anyway, yes, this can be a bogus issue, let's focus on the intuitive defs we have so far.

>
> > -M
> >
> > ps
> > Just to illustrate the kind of possible reasoning's:
> > For instance, do we really need explicit versioning in v1 (explicit versus implicit versioning using namespaces)?
>
> Yes, see [1] for a use case. Also see Jim's message [2] which states
> that how to handle versioning is a frequently asked question about the
> Semantic Web. Oh, and then there's our requirements document.
I wasn't there at the reqdoc time, but well, versioning is quite important, and I wouldn't argue to take the requirement out for v1,
provided we can find a reasonably simple way to do it. So, yes, let's consider the reqs are in place, and see if we can set them
nicely.

>
> > If we do, then
> > shouldn't it be "in RDF"?
>
> Why? So far, I've heard many people argue no, and you are the first to
> say that it should.
I remember at least Jeremy recently expressing problems with this ([2]), but anyway, what matters are motivations, and I seem to
remember people were not contrary to put these things in RDF "per se", but because they didn't think it was easily possible without
causing problems.
On the other hand, the main motivation pro "in RDF", as stated in [3], is that doing otherwise, you lose the info when
transporting/handling RDF.

> >If we don't, then the "thing" is just the import,
>
> That does not follow at all.
?? I think you misinterpreted (sorry, it is probably my abuse of English): as the "thing" was versioning+import, if we don't (need
versioning), then the "thing" to settle remains "import".

> > and at then point, once clear what import we need, it
> > might end that we can just use XInclude, as Raphael nicely showed, and therefore don't get trapped in the issue at all :)
>
> For reasons I've mentioned elsewhere, I cannot live with the XInclude
> solution. I have also heard a few others say this solution is
> unacceptable.
As far as I remember, Raphael replied to both your and Jim's problems. Did I miss something?
This, not to say I second entirely the xinclude (because, yes, it's outside RDF....).


Now, to be more constructive (and, all based on the intuitive defs we have for import and versioning), some quick solutions to put
everything "in RDF":
a) versioning: all the current problems with putting versioning in RDF is because of the heritage of DAML+OIL, that defines an
ontology in a "classic" file-based way. Defining ontologies in less orthodox ways, like using URIspaces (simple URI matching) might
elegantly solve this.
b) import: we can just use a triple
(bnode) -- rdfs:seeAlso --> (URI)
Depending on a precise def of import, we might want to strengthen this using a new rdf:import or the like, that gives the import an
rfc2119-SHOULD state (processors should fetch the RDF content at the URI and incorporate it (merge the graph)).
To be picky, note that because of a), we might be more formal and, in our particular OWL case, use things like
(ontologyURIspace) -- rdfs:seeAlso --> (URI)
gaining in declarativity (and possibly in OWL performance).

-M




[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0378.html
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0380.html
[3] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0382.html

Received on Wednesday, 25 September 2002 13:19:06 UTC