Manos Batsis wrote:
> With pleasure. As you know an RDF statement is a triple. It
> is composed
> of a subject (a resource), a property(predicate) and a property
> value(object). RDFS defines what properties are appropriate for a
> certain type of recourse and what kinds of values it can hold. Because
> RDF Schema does not validate structures but the model behind them, it
> can be used to validate even non-XML (i.e. n3) formats that
> can describe
> an RDF graph.
If we agree that XML adoption is going to drive the semantic web, then the
benefits of smoother integration with XML far outweigh the advantages of
annotating other formats. Once again, back to the SOAP vs. REST debate. SOAP
supports transports other than HTTP, but it isn't nearly as good *for* HTTP.
Since HTTP is the dominant paradigm, the trade-off falls heavily toward
REST. The paradigm is a lot less well established for semantic web-type
stuff, but I personally believe fervently that all the work being done to
create XML schemas is not effectively leveraged by RDF (to the extent that a
separate RDF schema is used).
> What keeps you from doing that today using both RDF(S) and XSD (or any
> other)? I cannot understand why you wish to merge two different things
> in one place.
Too much duplicated work. And I'm not proposing merging them in the same
place, I'm proposing using a separate annotation file (or several, for that
matter).
> But you did not attached DC semantics to an element type. Vanilla XML
> interprets namespaces in a very different manner than RDF. My
> point here
> is that when parsing RDF, you get an RDF graph. Getting in the process
> of extracting the annotations you need to validate the graph makes you
> dependent on the XML parser you use for XSD validation. Why
> having such
> dependencies?
I'm interested in your comment on namespaces. Can you elaborate on that?
As far as the parser is concerned, I imagine that you could extend a SAX
parser with a module that understands the annotations (basically just the
RDF model expressed using a more natural XML-schema-related syntax) and
exposes the model to the user (using RDF mechanisms, as far as I'm
concerned). I don't really see why the parser itself would need to do
anything besides validate the document and generate SAX events.
> > proposing is much more approachable because it doesn't force
> > you to work
> > inside an entirely new model.
>
> Now this cannot be true. To validate RDF statements you need to deal
> with the RDF model, whether you do it through RDFS or
> MakeMyML. It also
> makes application design much less flexible.
OK, I guess I meant "an entirely new syntax" rather than "an entirely new
model".
> RDFS is much better in this aspect; because it implements OO design
> structures. Throw a new property in the basket, associate it with a
> Class and voila. Global, non-document centric awareness.
This is exactly the view that I am arguing against. We *want*
document-centric awareness!
> To summaries, we share some objectives but disagree on the
> implementation specifics. You feel comfortable in XSD; I want clean
> separation. Perhaps you would agree to a mutual
> compromization by using
> annotations that *point to* RDFS modules? These would not be needed by
> an RDF document (you don't even need to specify a schema in
> such a file;
> URIs of resources should make it work for you).
Yes, we're no *so* far apart. Like Paul said, the devil is in the details.
One point of clarification: I'm not necessarily comfortable in XSD. The
approach I am proposing works with any XML schema language.
> IMHO, even a more clean separation of tasks is appropriate; that's why
> RDDL is so favored in this list.
OK, I need to look more closely at RDDL.
Matt
