- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 04 May 2004 19:43:50 +0100
- To: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Cc: Karl Dubost <karl@w3.org>, www-qa-wg@w3.org, www-qa@w3.org
The relationship between RDF Semantics and OWL Semantics might be relevant to this discussion. OWL Semantics (section 5) is explicitly an extension of RDF Semantics, and RDF Semantics gives explicitly permission and prohibitions on semantic extensions. To give you a flavour of the difference ... RDF lists are constructed in the same way as lisp lists, with each element being formed by a pair of pointers - one to the next element (using a property *rdf:first*), the other to the rest of the list (using a property *rdf:rest*). RDF Semantics says that usually these lists are well-formed and finite, i.e. each part of the list has one rdf:first and one rdf:rest, and the rdf:rest is either a list or *rdf:nil* (the empty list). However, this is not given MUST force. RDF Semantics specifies that semantic extensions MAY give these constraints MUST force. OWL takes RDF up on this, and hence when using rdf:first and rdf:rest in OWL, the lists MUST be well-formed and finite, whereas the same construct in RDF does not have these constraints. ==== So: OWL uses an extensibility point that is in RDF. The meaning of an RDF construct is changed by reading it in OWL. I think that is an extension ... using a defined mechanism. It is also permittted to make other sorts of semantic extensions (not just ones that have been preplanned), but there are a few key MUST NOTs about a semantic extension, that ensures a degree of interoperability. I'll be happy to review extensibility text in light of this experience (and the OWL and RDF experience in light of extensibility text). Jeremy Lynne Rosenthal wrote: > > This is helpful. It basically says that, you can extend the > specification by using the defined mechanism. In the case of XHTML, the > mechanism takes the form of a set of conformance rules. > > This is in contrast to Mark's view (which I finally understand) - His > view is that, if you use the defined mechanism, then it isn't an > extension. Extensions are adding new features beyond what is defined in > the specification, but not using any provided hooks or other mechanisms > in the specification. Thus, if a specification provides a "standard way > to be non-standard" by including hooks in the specification or other > mechanisms by which new functionality may be added in a conforming way - > then what is added, is not an extension. > > With Mark's definition, profiles, modules, levels are not considered > extensions. > Also, note that we define profiles, modules, and levels as ways to > sub-divide the specification - this implies no new features can be added > to profiles, modules, levels --- since if you add something, it won't be > a subset of the specification. > > Any comments? > > Lynne. > > > > > > > > > > At 02:27 PM 5/3/2004, Karl Dubost wrote: > >> Lynne & al. >> >> I went through a few specifications to find examples of "extension >> mechanisms". >> >> * XHTML Modularization [1] >> >> -> Modularization helps extensibility >> """Modularization also allows for the extension of XHTML's >> layout and presentation capabilities, using the extensibility >> of XML, without breaking the XHTML standard. This development >> path provides a stable, useful, and implementable framework >> for content developers and publishers to manage the rapid >> pace of technological change on the Web.""" >> >> The mechanism for extensibility is basically defined by rules of >> conformance. XHTML Modularization defines the notion of a family. You >> belong to the family if you respect certain criterias which are defined >> in "3.3. XHTML Family Module Conformance " [3], you have in fact a >> >> -> 1st: You define the extension by using W3C Technonologies >> => i.e. XML DTD or XML Schema. (exit RelaxNG it seems) >> -> 2nd: The extension is defined with a unique identifier. >> => Here the naming rules are defined >> -> 3rd, 6th: The features are uniquely recognizable >> => Here unique prefixes or a similar method >> => Unique namespace for defined modules >> -> 4th: The features are clearly described and documented. >> => Here syntactic and semantic requirements >> -> 5th: An extension never override things which are already defined. >> => Though they seem to soften it a bit by authorizing similar >> things >> if it has its own namespace, for example. >> >> So an extension is >> an addition to the technology >> which is uniquely identifiable >> and do not redefine behaviour of the technology it extends >> and can have some organization and naming constraints defined >> by the >> technology it extends. >> >> They also give examples of DTD implementations >> >> And I have realized, that in [3], there's a normative section which is >> not written!!! >> >> [1] http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ >> [2] >> http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- >> modularization.html#a_schema_developing >> [3] >> http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- >> modularization.html#s_conform_module >> >> >> * Behavorial Extension to CSS [4] >> >> I don't know what will become of this document (The last working draft >> is from 1999à but it's interesting to read. The document proposes to >> use scripting feature driven by CSS selectors. It defines an extension >> on CSS, redifining or copying another W3C technology (DOM). >> >> For example, proposition of a >> @script "text/javascript"; >> instead of the traditional (X)HTML >> <script type="text/javascript" /> >> >> The benefits envision here is to make it reusable for any kind of XML >> documents, but in a sense it could be done with a: >> <xhtml:script type="text/javascript" /> >> >> >> The question illustrated is a technology by an extension mechanism can >> redefine another technology. >> Can CSS redefines some behaviour of XHTML, DOM? >> Can SOAP redefines some property of HTTP? >> etc. >> >> [4] http://www.w3.org/TR/1999/WD-becss-19990804 >> >> >> * CSS-3 >> >> I can't find the document right now which defines CSS-3 extensibility, >> but basically the first draft which has been given to me was defining a >> very clear mechanism (scheme) to name the new selectors. >> >> -vendor-name-features >> >> + minus to start >> + vendor identification >> + name of the features >> >> But if I remember they were no requirements that the documentation >> explaining, describing the feature was published. Maybe there should be >> a clear policy about that too. >> I see few minor caveats: >> + vendor identification, name conflict: It will not happen >> often, but >> it might happen. >> + if we ask for a clear description of the created extension, >> where >> this documentation should be? >> Usually we have the requirements to put in a clear and >> *stable* place >> (Cool URIs don't break), though it's not often the case. Should we >> encourage people to send them to www-archive? or to have a kind of Web >> repository like www-archive. >> >> >> I will continue to try to find new examples. >> >> >> -- >> Karl Dubost - http://www.w3.org/People/karl/ >> W3C Conformance Manager >> *** Be Strict To Be Cool *** >> >> >
Received on Tuesday, 4 May 2004 14:44:18 UTC