rdfs-xml-schema-datatypes: A
suggestion that the RDF Schema Spec might usefully use XML Schema
datatypes in examples and/or in some formal specification of the mapping
of these datatypes into the RDF model. (Sergey Melnik)

Issue rdfms-quoting: The syntax needs a more convenient way to express
the reification of a statement.

Summary: The syntax currently allows the expression of the reification of
a statement by describing a resource with four properties. A more convenient
way of doing this is desirable. Tim is currently using parseType="Quote".

Summary: The RDF XML syntax uses XML qnames to represent property URI's.
However, not all possible property URI's, for example,
http://acme.com/property/ can be represented in this manner. This is an
example of a more general issue, that the RDF XML syntax cannot represent all
possible RDF models.

Currently, resource identifier values specified in attributes such as
"about", "resource", "aboutEach" and "type" are specified as URI-references.
The same resources used in element or attribute names are specified as
Qnames. Other specifications permit the use of Qnames in attribute values. It
would enhance readability of RDF were also to do so.

Summary: RDF has an "open grammar, which is harder to validate simply (and
nigh on impossible to do properly with DTDs). - Syntax validation within the
context of RDF embedded in other XML grammars would be easier if the RDF
syntax were only of the 'Fixed-Schema' variety, see
[http://lists.w3.org/Archives/Public/www-rdf-interest/2001Apr/0346.html ].
Currently, the propertyElt construct, and abbreviated forms of RDF are of the
'Schema-follows-data' variety.

The WG resolves to postpone rdfms-validating-embedded-rdf for later
consideration on the grounds that it is out of scope of its current charter
to change the current RDF/XML syntax to the extent necessary to address
it.

During the last call process of the RDFCore WG further comments (xmlsch-10,
xmlsch-12)
in a similar vein were received and again the WG decided
to postpone. There are strong calls for a new XML syntax for RDF; note Mark
Butler's comment on the postponement decision.

Summary: Given web principles, there can in general be no centralised
authority which defines the 'correct' URI for any given entity. Should the
core RDF specs define a property that specifies two resources to be
equivalent?

Whilst the WG recognises the importance of a mechanism for defining
equivalence of URI's, the WG has decided it does not fit within the scope
of its current charter. The WG notes that DAML+OIL has an equivalence
mechanism which raises the question of which layer of the stack best suits
such functionality. The WG also notes that by allowing cycles in
rdfs:subPropertyOf and rdfs:subClassOf RDF Schema provides a related
mechanism for properties and classes. Consideration of this issue will be
postponed.

The use of special property names (_1, _2, etc.) can really be quite
awkward for expressing ordering. It means that it can be very difficult to
add new members to a collection after the event, since the agent doing the
adding cannot be sure of knowing what property name to use. This seems to
violate the idea of being able to add new RDF statements to any resource at
any time.

For non-ordered collections, why not just use 'li' properties? (I
suppose one answer would be if multiple instances of a triple are not
allowed.)

For ordered collections, why not a linked graph structure -- e.g. a
'Cons' class with 'car' and 'cdr' properties?

RDFCore resolves to postpone this issue on the grounds that it would
require extensive changes to current spec, is not a critical requirement
for webont, that it would involve considering several different approaches,
taking time and consequent changes to syntax draft, test cases,
implementations and primer.

Summary: RDF is not just a data model. The RDF specs should define a
semantics so that an RDF statement on the web is interpreted as an assertion
of that statement such that its author would be responsible in law as if it
had been published in, say, a newspaper.

Summary: A request that there be a mechanism to enable applications to
take into account the relationship between different languages when doing
language comparisons, i.e. that "en" is, in some sense, a generalisation of
"en-US". This issue has been combined with a WG decision to add a postponed
issue to define URI's for languages.

Consideration of this issue should also include consideration of
standard mechanisms for representing language information about literals as
triples in an RDF graph.

Resolution: On 04 Apr 2003, the RDFCore WG resolved
to postpone this issue.

Currently: postponed

Issue rdfs-fyi: A request for a semantics free predicate for
comments.

Summary: Ian notes that rdfs:comment has semantics, in the sense that a
change to an rdfs:comment changes the formal meaning of an ontology. Ian
requests a facility for 'real' comments that have no semantics. Rather than
change rdfs:comment, Dan Connolly suggested
adding a new property.

Resolution: On 11 Apr 2003, the RDFCore WG resolved
not to change the semantics of rdfs:comment, and on 02 May 2003 it resolved
to postpone this issue.

Summary: Jeff and others (see also qu-03)
have requested the defintion of a subset of RDFS that follows a more
conventional layered architecture, where for example, rdfs:Class is not a
member of itself.

Resolution: On 18 Jul 2003, the RDFCore WG resolved
to create a postponed issue to ensure that it is considered by a future
WG.

Summary: Specifications for languages that embed RDF in them should
defer to the RDF specs for the interpretation of fragment identifiers
defined in embedded RDF.

Discussion:

Consider say, an SVG document, that contains embedded RDF that
defines a fragment identifier. The SVG specification should say that
the fragment identifier should be treated as an RDF fragment
identifier. It has been suggested that this may be a general issue
for the TAG about the treatment of fragment identifiers when one
language is embedded in another.

Analysis: According to (the non-normative) Appendix A.2 in the
'Namespaces in XML' spec, attributes with a prefix are in the 'Global
Attribute Partition' wheras attributes without a prefix are in the
'Per-Element-Type Partition'. Hence rdf:resource and resource may share a
localpart. However they are entirely distinct entities (at least
syntactically).

Examples in the RDF spec interchange the qualified and unqualified
attributes at different points. Specifically 'rdf:about', 'rdf:type',
'rdf:resource', and 'rdf:value'. The tendancy in the spec is to use
unqualified attributes for basic RDF syntax examples and qualified
attributes for second and third RDF abbreviated form examples - in these
cases the element type is (usually) not in the RDF namespace, so the
attribute is given the RDF prefix.

A suggested solution is to use global (qualified) attributes throughout.
In order to make the syntax slightly more forgiving, parsers should treat
any per-element-type attributes on RDF elements the same as their global
counterparts.

On 25th May 2001, the WG decided that ALL
attributes must be namespace qualified. There is a description
of the decision, including detail on the grammar productions affected and a
collection of test
cases.

On 1st June 2001, the WG decided
that aboutEachPrefix would be removed from the RDF Model and
Syntax Recommendation on the grounds that there is a lack of implementation
experience, and it therefore should not be in the recommendation. A future
version of RDF may consider support for this feature.

Summary: It is unclear whether an empty property element represents a
empty literal or an anonymous resource. Consider the case:

<rdf:Bag>
<rdf:li></rdf:li>
</rdf:Bag>

The applicable text of section 6 of the Model and Syntax specification
states:

3. (same as rule 3 above) If E is an empty element (no content), v is the
resource whose resource identifier is given by the resource attribute of E.
If the content of E contains no XML markup or if parseType="Literal" is
specified in the start tag of E then v is the content of E (a literal).
Otherwise, the content of E must be another Description or container and v
is the resource named by the(possibly implicit) ID or about of that
Description or container.

In this case E is an empty element but there is no resource identifier.
Similarly, E contains no XML markup, but has no content.

Summary: Parags 189-193 of M+S suggest a privileged role for RDF
containers within the formal model at the heart of RDF. Furthermore, they
suggest largely unimplemented (**need to hear about Jan's implementation**)
constraints, either on XML encodings of RDF, on other (eg. database
implementations) or on both. These paragraphs are either in error (RDF does
allow for partial descriptions) or editorially redundant.

Resolution: On 8th June 2001 the WG decided
that an RDF model may contain partial descriptions of a container. Thus an
RDF model is not contrained to have the containermembership properties
contiguous starting from rdf:_1. The following therefore, is legal RDF:

Summary: The RDF grammar defined in the Model and Syntax Specification is
ambiguous. Containers such as rdf:Bag, rdf:Seq and rdf:Alt match the
container productions 6.25 through 6.31, but also match the typedNode
production (6.13). The container productions attempt to restrict what the
language can express about containers, but the ambiguity in the syntax
effectively circumvents those restrictions.

On 29th June 2001, the WG decided
that containers will match the typed node production in the grammar (M&S
Section 6, production 6.13) and that the container specific productions
(productions 6.25 to 6.31) and any references to them be removed from the
grammar. rdf:li elements will be translated to rdf:_nnn elements when they
are found matching either a propertyElt (production 6.12) or a a typedNode
(production 6.13). The decision includes a set of test
cases.

Currently: closed

Issue rdf-containers-syntax-vs-schema: The RDF Model collection classes
(Bag, Seq, Alt) require parsers to have special knowledge of container
semantics, making it difficult to subclass these

Summary: The RDF collection classes (Bag, Seq, Alt) are somewhat irregular
in their construction from the XML syntax. Specifically, the RDF parser needs
to have special knowledge of these classes in order to recognize that the
contained rdf:li properties are really rdf:_1, rdf:_2, etc.

This in turn means that it is not possible to define RDF applications and
corresponding schema that declare subclasses of the collection classes for
specific purposes, but which can also be treated as any collection class,
because a non-schema-aware parser would not know to translate the <li>
elements into <_1>, <_2>, etc.

On 29th June 2001, the WG decided
that containers will match the typed node production in the grammar (M&S
Section 6, production 6.13) and that the container specific productions
(productions 6.25 to 6.31) and any references to them be removed from the
grammar. rdf:li elements will be translated to rdf:_nnn elements when they
are found matching either a propertyElt (production 6.12) or a a typedNode
(production 6.13). The decision includes a set of test
cases.

Summary: The restriction that cycles of subClassOf relationships are
prohibited is too restrictive. Cycles of subClassOf relationships are
necessary, for example, to represent equivalence between two classes. The
submitter contends that cycles of subclass relationships are essential for
KR/Ontology languages.

To resolve issue rdfs-no-cycles-in-subClassOf by deleting the restriction
prohibiting cycles of subClassOf properties. The meaning of a cycle of
subClassOf properties being an assertion that the classes involved have the
same members. A more formal specification of the meaning will be given in
the model theory.

Deleting the restriction prohibiting cycles of subPropertyOf properties.
The meaning of a cycle of subPropertyOf properties is an assertion that the
properties involved in the cycle have the same members. A more formal
specification of the meaning is given in the model theory.

Summary: The Model and Syntax specification defines the concept of
anonymous resources, i.e. resources with no URI represented in the RDF graph
or XML serialization. Many parsers automatically generate URI's for such
anonymous resources in the triples they produce. Such URI's are often
referred to as genid's. Different parsers create different genid's for the
same XML input. This raises a number of questions:

Should anonymous resources have URI's?

If so, should the be clearly distinguishable as parser generated
URI's?

Should there be a standard algorithm for generating URI's which ensures
that different parsers generate the same URI's from the same source input
document?

How might these automatically generated URI's be affected by changes in
the source document?

If anonymous resources are not labelled with a URI, then it is not
possible to represent arbritary graphs with the current RDF XML syntax. For
example:

The current mechanism, rdfs:ConstraintResource and
rdfs:ConstraintProperty, fails to serve its original purpose and should be
removed from the RDF Schema 1.0 specification. The accompanying text be
amended accordingly.

The WG closes rdfms-resource-semantics on the grounds that the model
theory says all that RDF is normatively going to say about the nature of
resources. Further specification of the nature of resources is the work of
other WG's.

Summary: The current RDF terminology is inconsistent with the long
established terminology used by logicians. For example, what RDF'er's call a
'model' is called an 'abstract syntax' by logicians. Logicians use the term
model but for something quite different.

Issue rdfs-domain-and-range: Should a property be allowed more than one
rdfs:range property? What should the semantics of multiple domain and range
properties be?

Summary: Ontology languages such as OIL permit multiple
range restrictions on a property. If they are to be built on top of RDF
Schema, they require the same flexibility. There has been further discussion
on how multiple range constraints should be interpretted. Conjunctive
semantics requires that a property is constrained by the conjunction (and) of
its range constraints; disjunctive semantics require that the property is
constrained by the disjunction (or) of its range constraints. It has also
been suggested that the semantics of domain constraints be revisted, as
development experience has shown the current semantics of domain not to be
useful for inference. Further, some symmetry between rdfs:domain and
rdfs:range would be expected since the domain of a property is the range of
its inverse and vice versa.

Issue rdfs-primitive-properties: A suggestion that properties such as
rdfs:subClassOf, rdf:type and others should not be instances of rdf:Property,
but should be primitive.

Summary: The submitter suggests that the properties rdfs:subClassOf,
rdf:type, rdfs:domain and rdfs:range should not be defined as instances of
rdf:Property, but should instead be primitive. It is contended that rdf would
then be less self referential and easier to understand. The argument is
documented in The
RDF Schema Specification Revisited

[Equivalence]: There are four RDF model "flavours" (formal/data model,
graph(ical) model, serialization syntax, triple). To what extend
(precisely) are these models (not) equivalent? (Problems related to
anonymity have been discussed, see also below, details need to be
summarized). Could trying to find transformation grammars be a solution
(preciseness, determination of equivalence)? Shouldn't this be in a
"formal" part of M&S spec?

Currently: this is a broad topic. Investigation into the notion of a
'better syntax' also touches on this problem: we need to be clear on the
boundaries between Model and Syntax, particularly in areas such as 'anonymous
resources' which have caused developers some confusion.

the diagrams of graphs used in documents such as the RDF Model
and Syntax document

are currently all equivalent

The WG resolves to maintain that equivalence (this is a statement of
intent rather than a certified fact)

The WG notes that the RDF/XML syntax as currently defined is unable
to represent an arbritary RDF graph. In particular, the RDF/XML syntax
cannot fully represent a bNode which is the object of more than one
statement.

The WG believes that extending the RDF/XML syntax so that it can
respresent all RDF graphs is beyond the scope of its current charter
and resolves to postpone consideration of this issue.

The WG actions the editor of the RDF Syntax WD to include in that
document a clear statement of the RDF graph structures that RDF/XML is
unable to represent.

Summary: There are gotchas in representing the current RDF model in a
logical formalism. For example, a statement is defined as triple containing
containing at least two, possibly three resources. Resources are not
reasonable things to include in a triple.

What are the members of #books? Is #book2 one of them? I can deduce, from
the specification of rdfs:subProperty, that it is. But knowledge of
rdfs:subProperty is not required for parsing rdf:aboutEach syntax, is it?

It has also been suggested
that aboutEach is difficult to implement for streaming parsers, which have to
retain information about containers in case they encounter a statement with a
distributive referrent to that container.

Resolution: On 7th December 2001, the RDFCore WG resolved
to remove rdf:aboutEach from the RDF specifications.

Summary: M&S Spec says that "The Description element itself represents
an instance of a Bag resource...". Does this mean that a parser MUST create a
Bag of reified statements for every Description Element?

a parser is not required to create bags of reified statements for all
rdf:Description elements, only those which are explicitly reified using an
rdf:ID on a propertyElt or by an RDF:bagID on the rdf:Description.

Summary: The algorithm for mapping a QName in the RDF XML syntax to a URI
is to concatenate the URI of the namespace with the localname part of the
QName. In the case of namespaces, such as the XML Schema datatypes namespace,
which do not end in a "#" character, then the URI reference generated by this
algorithm is not the same as the conventional URI for the concept.

For example, the XML Schema QName xsd:unsignedInt is referenced using
http://www.w3.org/2000/10/XMLSchema#unsignedInt, whereas the RDF translation
of this QName is http://www.w3.org/2000/10/XMLSchemaunsignedInt.

It is proposed that the algorithm be modified, so that, when the URI of
the namespace ends in a letter or an "_" character, then the URI should
consist of the URI of the namespace concatenated with a "#" character then
concatenated with the localname.

Issue rdfms-propElt-id-with-dr: Clarify the interpretation of an ID
attribute in the propertyElt production within a Description element with a
distributive referrant.

Summary: The RDF Model and Syntax specification states in section 6 that
an rdf:ID attribute on a propertyElt [6.12] production identifies the reified
statement which the propertyElt produces. In the case where the propertyElt
is within a Description element with a distrubitive referrent, such as
aboutEach or aboutEachPrefix, the propertyElt represents many statements
which cannot all share the same ID.

Summary: Communication and discussion within the community interested in
RDF is hampered by lack of a disciplined terminology. It is suggested that a
glossary of terms be developed to aid effective communication. This is a
general issue for all RDF specifications.

The issue originally raised is whether an RDF graph should have a URI
(rdfms-uri-for-graph). There have also been proposals for algorithms for
generating URI's for RDF graphs aka models.

This is an aspect of a broader issue that the RDF Model and Syntax
recommentation discusses the concept of an RDF graph but does not
define/describe it in the RDF formal model section. The term 'model' is often
used as a synonym for an RDF graph.

Summary: The RDF data model distinguishes between resources and literals.
Only resources may be the subject of a statement. The data: URI scheme
enables data to be encoded in the URI of a resource. Thus literals could be
represented as resources with data URI's. Such resources could be the subject
of a statement. Then, for example, if a string literal were represented as a
resource with a data: URI, the language of that property value, could be
represented as a property of that resource.

Summary: "The object being the union of literal types and reference to
node is reasonable: the object may be represented as a pair (type, value) for
example (or some other syntax or a pointer into a different part of memory or
a pointer to a self-typed object or whatever.) ... You could argue (and
people have i understand) that the same ought to hold for the subject of
course."

Resolution: On the 15th February 2002, at the RDFCore WG telecon,
the WG:

resolved that the current syntaxes (RDF/XML, n-triples, graph syntax)
do not allow literals as subjects.

noted that it is aware of no reason why literals should not be subjects
and a future WG with a less restrictive charter may extend the syntaxes
to allow literals as the subjects of statements.

Summary: "an xmlns-qualified name is a pair of (namespace URI, name);
there is no composition function implied apart from the trivial 'shove both
bits into a pair'. But RDF claims that resources are (or are identified by)
URIs only; there seems to be an (implicit? explicit?) composition function
that takes the namespace and the name part and produces a URI from them."

A further related question has been raised. Namespaces are used as an
abbreviation in the syntax - are they syntactic sugar or part of the
model?

resolves to close this issue on the grounds that changing how resources
are named on the web is a web architecture issue and beyond the scope of
our charter.

Whereas:

the RDF 1.0 spec says that property and class names are computed from
element and attribute names by concatenating their namespace names with
their local names

it's useful to be able to process RDF with XPath and XSLT, where even
though

concat(namespace-name(qname1), local-name(qname1))

is the same as

concat(namespace-name(qname2), local-name(qname2))

the qnames themselves may not compare equal in XPath expressions.

lots of implementors have looked for advice on how to serialize RDF,
and, in particular, how to compute a namespace name and localname from
the name of a property or a class.

the WG advises RDF schema/namespace/vocabulary designers choose
namespace names that end in non-xml-name-characters such as / # ?

we advise implementors of RDF serializers in order to break a URI
into a namespace name and a local name, split it after the last XML
non-name character. If the URI ends in a non-name-character throw a
"this graph cannot be serialized in RDF 1.0" exception.

No standard vocabulary is defined for representing boolean valued
properties. The author of this suggestion proposes the introduction of two
new properties, rdf:is and rdf:isNot. To represent the fact that someone
likes chocolate, their resource could have the property rdf:is with a value
of foo:ChocolateLover.

Resolution: At the 15th February 2002 telecon,
the RDFCore WG decided:

The WG notes that since a boolean-valued property can be identified with
a class, rdf:type can be used to represent boolean valued properties.
Thus:

The WG notes that RDF(S) defines no built in mechanism for expressing
that ChocolateLover and ChocolateHater are disjoint classes. The WEBONT WG
are defining mechanisms for such expressions. The WG resolves to close this
issue.

Summary: The grammar does not permit the use of an ID attribute to assign
a URI to the reification of a statement where the object of the statement is
specified by an rdf:resource attribute.

The RDF Model and Syntax recommendation states that the value of an ID
attribute on a propertyElt production [6.12], if specified, is the identifier
for the resource that represents the reification of the statement. However,
the grammar does not permit both an ID attribute and a resource attribute to
present in the same production. Thus:

A bagID reifies the property attributes on the same element as the
bagid, the type node and statements immediately arising from property
elements that are immediate children of the element containing the bagId.
In particular a property element whose statement is part of the bag, which
has property attributes, those statements are not part of the bag.

The WG reaffirmed its decision not to restrict names in the RDF
namespaces which are not syntactic. The WG decided that an RDF processor
SHOULD emit a warning when encountering names in the RDF namespace which
are not defined, but should otherwise behave normally.

Summary: The property rdf:value is used confusingly and inconsistently
throughout the M&S and is never defined. Some have suggested it is used
for multi-valued properties (some suggest currying is a better way to do
this) and others have claimed it is for defining the lexical representation
of a resource. It is requested that the Working Group clarify its meaning and
usage.

Resolution: This issue was discussed
by the RDFCore WG on 11 January 2002 which resolved:

o resolves to not change the name of this property at this time on the
grounds:

- insufficient reasons to make this change

- will cause existing uses to be illegal - such as examples in
m&s

o resolves to recast this issue as a need to clarify the semantics of
rdf:value.

The question of what, exactly, a URI fragment designates in the case of an
XML document that uses the RDF namespace is indeed an area that is murky in
the spec, I have recently realized. Part of your question has, I claim, a
single consistent answer and part has several feasible answers.

One particular aspect of the '#' issue is that the semantics of the
fragment identifier in URI references is relative to a mime type:

RDF uses URI-references to identify rdf resources. But the meaning of a
fragment identifier is defined only in terms of the MIME type of an entity
associated with the resource identified by the URI part. How does the RDF
square up to this? What is the MIME type according to which the fragment
identifier of an RDF resource identifier is interpreted? Does it depend on
the RDF resource involved?
Graham Klyne www-rdf-interest@w3.org
from September 2000: RDF Issue Tracking Wed, 06 Sep 2000 10:04:07 GMT

This problem elaborated on with examples:

'#' is a downright broken bit of web architecture. The '#' fragment/view
semantics are defined as being relative to the mime type of the object.
Since mime types can be content-negotiated, that's hairy since a single URI
plus '#' doesn't mean much without additional assumptions about mime types.
For example, http://www.w3.org/Icons/WWW/w3c_main has both GIF and PNG
mime-typed variants. So the semantics of
http://www.w3.org/Icons/WWW/w3c_main#foo can't be considered outside the
context of some HTTP transaction, since the mime type of the resource isn't
an instrinsic property of the resource identified.
Dan Brickley, www-rdf-interest@w3.org
from March 2000: Re: Subclass of Thing/ Sat, 04 Mar 2000 00:24:21 GMT

An RDF specific solution to perceived deficiences in
exclusive canonicalization would not be interoperable with
other ad hoc solutions.

Long term, a solution based on a generic XML solution,
perhaps not dissimilar to XML fragments, would be better.

The simplicity of the current design will encourage
deployment of XMLLiteral, which will aid
internationalization concerns.

An important consideration, reflected most in the comments
from the Web Ontology WG and Patel-Schneider's concerns, is
that unless rdf:XMLLiteral is a normal datatype with no
special treatment of language, then OWL Lite and OWL DL do
not support it. No version of the OWL Abstract Syntax has
permitted literals other than plain literals (with or without
language tags) or typed literals (without a language tag).
Thus, any solution, other than the last two of the four
above, would require substantive changes to OWL DL and OWL
Lite.

"There is a question whether or not there can be two different statements
with the same subject, object and property. Most people seem to say "no". I
have suggested that this should be allowed because it can be expressed in
reified RDF statements and that there should be a 1:1 correspondence
between what can be expressed in an RDF model and its reification. "
www-rdf-interest@w3.org
from September 2000: RDF Issue Tracking Wed, 06 Sep 2000 10:04:07 GMT

The RDF Model and Syntax REC says:

This specification shows three representations of the data model; as
3-tuples (triples), as a graph, and in XML. These representations have
equivalent meaning. The mapping between the representations used in this
specification is not intended to constrain in any way the internal
representation used by implementations.

The RDF data model is defined formally as follows:

There is a set called Resources.

There is a set called Literals.

There is a subset of Resources called Properties.

There is a set called Statements,
each element of which is a triple of the form {pred, sub, obj} Where
pred is a property (member of Properties), sub is a resource (member of
Resources), and obj is either a resource or a literal (member of
Literals).

Notes: the set-theoretic language of the Formal RDF model
specification has often been cited on www-rdf-interest as evidence that the
'same' statement cannot appear multiple times within a given model.

This is issue is related to the extensive discussion that has occurred
concerning the distinction between statings and statements as pointed
out by Dan Brickley.

Summary: The RDF XML syntax permits Literals which consist of XML markup.
Is the value of the literal the string of characters as they appear in the
the source document? If it is, then the association of namespace prefixes to
namespace URI's may be lost. Alternatively, an RDF processor may be required
to modify the XML markup as necessary to preserve the association between
namespace prefixes and namespace URI's.

the exact form of the string value corresponding to any given XML
Literal within RDF/XML is implementation dependent.

the string value is well-balanced XML

taking the exclusive canonicalization of both the original XML
Literal in its containing document, and the string value of the literal
produce the same character string. (this will be used as the basis for
test cases)

the canonicalization above is without comments i.e. CONFORMANCE
should be tested by canonicalizing without comments; comments may be
included in the string representation of a literal

this issue is closed

to raise a comment on the XQuery/XPath 2.0 data model that it does
not adequately address the handling of namespace prefixes appearing in
attribute values.

Summary: The xml-base construct could be useful in defining the base of
relative URI's in RDF.

Resolution: The WG decided that it allow xml:base to affect the conversion
of relative URI refernces to absolute URI references. In particular it decided:

RFC 2396 states that self document references, such as rdf:about="", are
not relative URI's are thus not subject to being converted to an absolute
URI using xml:base. It was also noted in section 4.2 of RFC 2396 it
states:

However, if the URI reference occurs in a context that is always
intended to result in a new request, as in the case of HTML's FORM
element, then an empty URI reference represents the base URI of the
current document and should be replaced by that URI when transformed into
a request.

It can be argued that this case should cover RDF's use of URI's.

The WG decided that RDF will convert such references to absolute URI's
and will take in scope xml:base attributes into account in such
conversions. Specifically:

Resolution: On 5th April 2002, the RDFCore WG resolved this issue by
approving test cases white, black 1 and black 2 submitted
for consideration. The grey test cases were not approved; instead the WG
decided to add text to the syntax specification pointing out that literals
beginning with a combining character may not be serializable in RDF/XML,
depending on the outcome of CHARMOD, and may cause interoperability
problems.

Issue rdfms-para196:
treatment of namespace URIs beginning with the URI named in paragraph
196 of M+S

Summary: M&S special treatment of namespaces beginning with
"http://www.w3.org/TR/REC-rdf-syntax" has been widely misinterpretted as a
typo for the rdf namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#".

Resolution: On 30th November 2001, the RDFCore WG resolved
to delete this special treatment from the specification..

Summary: Applications cannot rely on the value of an rdfs:isDefinedBy
property refering to an RDF schema. It is suggested that further sub
properties of rdfs:isDefinedBy be defined, one of which is contrained to
refer to a schema and the other is constrained to refer to a
specification.

This property indicates a resource which contains information about the
subject. Often, this property is used to indicate the source of the subject
uriref, where its owner specifies its intended meaning. The subject node of
this property can be any uriref, and the value may be any document or
resource; the usage is not restricted to a particular form or schema

Summary: Some changes have been made to the RDF language (deletion of
aboutEach*) and definition of terms (rdfs:domain, rdfs:range). This would
normally call for a change of namespace URI's. If they are not changed, a
strong case must be made.

Summary: It is suggested that the novel use of subclass and instance
relationships in RDF will be hard for those familiar with object oriented
programming to understand and that a clearer discussion of the application of
these relationships, especially when the same resource is both an instance
and a subClass would be helpful.

Resolution: On 3rd May 2002, the RDFCore WG resolved:

subClassOf and rdf:type are defined in the RDF Model Theory

the RDF Schema spec and RDF Primer provide adequate descriptions of
these properties

Resolution: On the 17th June 2002, the RDFCore WG resolved this issue.
This resolution was described in in the RDF/XML Syntax document as:

If RDF/XML is embedded inside HTML or XHTML this can add many new
elements and attributes, many of which will not be in the appropriate DTD.
This causes validation against the DTD to fail. The obvious solution of
changing or extending the DTD is not practical for most uses. This problem
has been analysed extensively by Sean B. Palmer in RDF in HTML: Approaches[RDF-IN-XHTML]
and it concludes that there is no single embedding method that satisfies
all applications and remains simple.

The recommended approach is to not embed RDF/XML in HTML/XHTML but
rather to use <link> element in the <head> element of the
HTML/HTML to point at a separate RDF/XML document. This has been used for
several years by the Dublin Core
Metadata Initiative (DCMI) on its web site.

To use this technique, the <link> element href should point at the
URI of the RDF/XML content and the type attribute should be used with the
value of "application/rdf+xml", the proposed MIME Type for RDF/XML, see
Section 4 The value of the rel attribute may also be set to indicate the
relatioship; this is an application dependent value. The DCMI has used and
recommended rel="meta" when linking in RFC 2731 - Encoding Dublin Core
Metadata in HTML[RFC-2731] however rel="alternative" may also be
appropriate. See HTML 4.01 link
types and XHTML
Modularization - LinkTypes for further information.

Issue rdfms-seq-representation: The ordinal property representation of
containers does not support recursive processing of containers in languages
such as Prolog.

Summary: RDF containers, such as sequences are represented using ordinal
properties of the form rdf:_n. Sequences represented in this way cannot be
sorted recursively in languages such as Prolog. This has led to the
definition of the DAML+OIL list representation which can be easily processed
recursively.

to the premises, invalidates this entailment and is thus
non-monotonic.

After great effort to find a solution acceptable to all parties,
none was found, but the WG was able to build strong support for the
solution it proposes.

The Owl ontology languages designed by the WebOnt WG has
successfully integrated the proposed datatyping solution into its
design and now relies apon it. The proposed design has been
successfully implemented, for example in Jena and Euler. In the last
call comment process only one comment
relates to this datatype issue. The WG interprets this as evidence
that the proposed solution is broadly acceptable to the
community. Given the intensive effort already expended on this
problem, the WG suggests that a new solution attracting greater
support is unlikely to emerge.

On these grounds the WG asks the director to support the decision
of the WG despite outstanding dissent.