seeAlso: last call comments | 2nd last call comments
This is the issue tracking document of RDFCore Working Group.
The www-rdf-comments list is the appropriate method of communicating new issues or concerns to the RDFCore WG.
This document identifies and defines the status of issues considered by the RDFCore Working Group. It is a working document, and as such is subject to constant change as the WG proceeds.
none at this time.
The www-rdf-comments list is the appropriate method of communicating new issues or concerns to the RDFCore WG.
None at this time.
None at this time.
None at this time.
Raised ???, 31 Aug 2000 by Graham Klyne
Summary: The idea of contexts has occurred on several occasions on the mailing lists. Graham Klyne has written a detailed paper on the issue, and there are other uses of the term, e.g. in N3.
Further Discussion:
Currently: postponed (decision, response)
raised Thu, 18 Jan 2001 by Tim Berners-Lee
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".
See Also:
Further Discussion:
Currently: Postponed (decision, response)
Raised Wed, 14 Feb 2001 by Graham Klyne
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.
Further Discussion:
Currently: Postponed (decision, response)
raised Wed, 18 Apr 2001 by Graham Klyne
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.
Further Discussion:
Currently: Postponed (decision, response)
raised Thu, 14 Jun 2001 by Jan Grant
Summary: A graph which contains an anonymous resource which is the object of two statements cannot be represented in the RDF/XML syntax unless a URI is assigned to the resource.
In a nutshell, there is no way to represent the following (n-triple) model in RDF/XML:
_:a1 <http://random.ioctl.org/#p1> _:a2 .
_:a2 <http://random.ioctl.org/#p2> _:a1 .
See Also: rdfms-qnames-cant-represent-all-uris
On 26th July 2002, the WG decided to re-open this issue and accept the proposal (as amended) to add an rdf:nodeID to the syntax for specifying blank nodes in triple subject and object positions.
Currently: Postponed (decision, response)
raised Mon, 23 Apr 2001 by Lee Jonas
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.
Resolution: On 9th November 2001, the RDFCore WG resolved
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.
Currently: postponed (response)
The RDFCore WG asks the director support the working group's design despite the outstanding dissent on the grounds that:
Raised Wed, Jan 19 2000 by Eric Hellman
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?
Resolution: On the 9th November 2001, the RDFCore WG resolved:
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.
Currently: postponed (response)
Raised Sun, 18 Aug 2002 by Tim Berners-Lee
Summary: A request that the predicate of a statement may be a b-node to enable expression of the form:
{?x [ :inverse ?p] ?y} => { ?y :p :x }
Currently: 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?
It has also been suggested that:
a decent set of collection abstractions should provide for sets
See also:
this has proved a common concern on www-rdf-interest and www-rdf-comments. We need an overview of the various concerns and alternative proposals.
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolves this issue is out of scope for this WG but places the issue on the list of to be considered by a future WG.
Currently: for consideration by a future WG
Raised Sun, 18 Aug 2002 by Tim Berners-Lee
Summary: When RDF is embedded in another document, it is the enclosing document which determines whether the RDF statements are asserted. How should it indicate this to an RDF processor?
Currently: postponed
raised Thu, 08 Mar 2001 by Jim Hendler as a last call comment.
Summary: The parseType="Collection" syntax permits the compact representation of lists of resource, but not of literals.
See Also:
On 11 Mar 2003, the RDFCore WG resolved:
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.
Currently: postponed
raised Thu, 08 Mar 2001 by Dan Connolly
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.
On 23rd August 2002, the RDFCore WG resolved:
that the text in section 2.3.2 of the Concepts and Abstract Data Model document resolves this issue and it be closed.
However in the light of last call comments, the RDFCore WG resolved:
PROPOSED by GK to strike section 4 from concepts document see: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0029.html
SECONDED by EM
CARRIED with no objection or abstentions.
ACTION 2003-03-11#2, GK: Delete section 4 of concepts document
ACTION 2003-03-11#3, BWM: Move issue rdfms-assertion to postponed
ACTION 2003-03-11#4, EDs: Document editors to review documents for consequential changes
ACTION 2003-03-11#5, EM: Raise issue with SWCG "to prioritize further discussion ..."
ACTION 2003-03-11#7, GK: Respond to (various people) on pfps-14
See Also: The tag issue rdfURIMeaning and the discussion in the semantic web meaning forum.
Currently: postponed
Raised Fri, 28 Feb 2003 as a last call comment by Tex Texin
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
Raised Fri, 20 Feb 2003 as a last call comment by Ian Horrocks.
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.
Raised Fri, 15 Feb 2003 as a last call comment by Jeff Pan .
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.
Currently: postponed
Raised Mon, 01 Sep 2003 as a last call comment by Karsten Tolle .
Summary: A request to define a formal semantic relationship between lists and containers.
Currently: postponed
Raised Mon, 10 Nov 2003 Martin Duerst .
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.
Currently: postponed
Raised Mon, 07 Nov 2003 as a second last call comment by Martin Duerst .
A request that:
_:a eg:prop "foo"^^rdf:XMLLiteral . rdf entails _:a eg.:prop "foo" .
and vice versa.
Resolution: On 07 Nov 2003 the RDFCore WG resolved to postpone this issue with the rationale:
The lack of semantic equivalence between XMLLiterals and plain literals has been clear since the first WD of RDF Concepts, and was arguable in RDF Model and Syntax.
The RDF Semantics does not preclude RDF applications using additional information to determine that two literals are equivalent, but does not mandate that they should be.
Hence, RDF applications which require this equivalence may operate in such a mode, and so this issue is not a show stopper.
Currently: postponed (response)
Raised Mon, 07 Nov 2003 as a second last call comment by Sandro Hawke .
Summary: Sandro observes that the manifest format has an error.
Currently: postponed (response)
Raised Wed, 26 Apr 2000 by Dan Connolly (writeup by Lee Jonas).
Summary: unqualified RDF attributes on element types in the RDF namespace are _not_ equivalent to attributes with the RDF prefix.
see also: Namespaces REC, Namespace Myths article, Problem with the "rdf" namespaces in RDF Model & Syntax
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.
Further Discussion:
Resolution:
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.
Currently: Closed
Raised Tue, 29 Feb 2000 by mailto:[email protected]
Summary: Is it best to put it off to a level of logic above the basic RDF?
See also:
Resolution:
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.
Currently: Closed
raised Fri, 23 Feb 2001 by Karsten-A. Otto
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.
A similar issue arises in the case:
<rdf:Description> <foo:bar /> </rdf:Description>
Further Discussion:
Resolution.
On 8th June 2001 the WG decided how empty property elements should be interpreted. The decision is fully represented by test cases.
Currently: closed
raised Wed, 09 May 2001 by Dan Brickley
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:
<rdf:Bag>
<rdf:_2>2</rdf:_2>
<rdf::_4>4</rdf:_4>
</rdf:Bag>Currently: closed.
Raised Thu, 03 Aug 2000 by Dan Connolly
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.
See Also:
Resolution:
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
Raised Wed, Sep 06 2000 by [email protected].
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.
See Also:
Resolution:
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
Raised Tue, Aug 29 2000 by Stefan Kokkelink
Summary: M&S grammar permits an rdf:aboutEach attribute to be present on a description element which is the object of a statement. How should this be handled?
The RDF grammar permits the following:
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:DC="http://purl.org/metadata/dublin_core/">
<Bag ID="pages">
<li resource="http://foo.org/foo.html" />
<li resource="http://bar.org/bar.html" />
</Bag>
<Description about="URL1">
<DC:Prop>
<Description aboutEach="#pages">
<DC:Creator>Ora Lassila</DC:Creator>
</Description>
</DC:Prop>
</Description>
</RDF>
It is not clear what triples a parser should generate.
Ora Lassila has stated in a response that it was the intention of the working group that rdf:aboutEach attributes should be permitted only on top level description elements.
Resolution: On 29th June 2001, the WG decided that rdf:aboutEach attributes are not allowed on an rdf:Description (or typed node) element which is the object of a statement.
Currently: closed
raised Wed, 24 Jan 2001 by Stefan Decker
Summary: Is a sub-property of rdfs:subPropertyOf necessarily transitive? Ian Horrocks has provided a counter example.
Resolution: The WG decided that a subProperty of rdfs:subPropertyOf need not be transitive based on an explanation provided by Jan Grant.
raised Wed, 14 Jun 2000 by Michel Klein
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.
Further Discussion:
Resolution: on 21st Sept 2001, the RDFCore WG resolved:
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.
Test cases were also approved.
Currently: Closed
Summary: The restriction that cycles of subPropertyOf relationships are prohibited is too restrictive.
Resolution: on 28th Sept 2001, the RDFCore WG resolved:
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.
Test cases were also approved.
Currently: Closed
Raised Sun, Nov 21 1999 by Jonas Liljegren
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:
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:
[http://example1]--foo:bar-->[anon-resource]
/\
|
[http://example2]--foo:bar------
Further Discussion:
Resolution: On 19th October 2001 the WG resolved:
that the RDF model theory draft of 25 September 2001 (http://www.w3.org/TR/2001/WD-rdf-mt-20010925/) adequately addresses the issue http://www.w3.org/2000/03/rdf-tracking/#rdfms-identity-anon-resources
Test cases were also approved.
Currently: Closed (response)
Raised Thu, 20 Jul 2000 by Joe English
Summary: The language in section 6 describing the formal grammar is unclear.
See Also:
Resolution: On 26th October 2001, the WG resolved:
This issue is closed on the grounds that it is resolved by the new approach taken to defining the syntax.
Currently: Closed (response)
raised Thu, 22 Feb 2001 by Dan Connolly
Summary: The grammar in the RDF 1.0 spec is informal and should be replaced. Something based on XML Schema should be considerd.
Further Discussion:
Resolution: On 26th October 2001, the WG resolved:
This issue is closed on the grounds that it is resolved by the new approach taken to defining the syntax.
Currently: Closed (response)
raised Tue 09 Oct 2001 by Dan Connolly
Summary: Are constraint properties and contraint resources useful. If not, the eliminate them.
Resolution: On 9th Novemeber 2001, the WG resolved:
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.
Currently: closed (response)
Raised Sat, Nov 1999 by Jonas Liljegren
Summary: RDF describes resources. However, neither the concept of resource, nor how it relates to other concepts such as URI and entity, are precisely defined.
Specific questions that have arisen include:
Topic Maps, as described in the XTM Core Specification distinguishes between the concept of a topic, a similar concept to an RDF resource, and a subject which is the entity the topic represents.
See also:
Further Discussion:
Resolution: On 9th November 2001 the RDFCore WG resolved:
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.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
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.
Resolution: On the 9th November 2001, the RDFCore WG resolved:
The WG closes rdfms-logical-terminololgy on the grounds that the new terminology introduced by the model theory adequately addresses this issue.
Currently: closed (response)
raised Wed, 14 Jun 2000 by Michel Klein
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.
Further Discussion:
Resolution: On 2nd August 2001, the RDFCore WG resolved:
Multiple domain and range constraints are permissable and will have conjunctive semantics and this issue is now closed.
Currently: closed (response)
raised Thu, 10 Aug 2000 by James Tauber
Summary: The RDF representation of RDF Schema omits the rdfs:domain and rdfs:range constraints for rdfs:domain
Resolution: On 2nd August 2001, the RDFCore WG resolved:
Domain and range constraints on domain will be included in the next version of the schema document and this issue is now closed.
Currently: closed (response)
raised Tues, 6th Jun 2000 by Wolfgang Nejdl
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
Resolution: On 2nd August 2001, the RDFCore WG resoloved:
The issue rdfs-primitive-properties is not a problem and will be closed
Currently: closed (response)
raised Wed, 14 Jun 2000 by Michel Klein
Summary: The semantics of the subPropertyOf relationship is not clear with respect to the inheritance of domain and range constraints.
Resolution: on 2nd August 2001, the RDFCore WG resolved:
subProperties inherit conjunctively the domain and range of their superproperties
Currently: closed (response)
raised Tue, 01 Aug 2000 by Lee Jonas
Summary: The submitter is concerned about RDF schema's, once published, not being able to change. The introduction of a rdfs:deprecated property to enable controlled changes to schema is suggested.
Further Discussion:
Resolution: On 2nd August 2001, the RDFCore WG decided:
to close this issue without action since it is a known problem that is very hard to solve and is outside the scope of this WG.
Currently: closed (response)
Raised Wed, Sep 06 2000 by Wolfram Conen.
[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.
See also: RDF data model summary
Resolution: On 16th November 2001, the RDFCore WG resolved:
- The WG agrees that:
- the graph model which is the basis for the model theory
- the n-Triples representation of an RDF graph
- 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.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
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.
Resolution: On 9th November 2001, the RDFCore WG resolved:
The WG closes rdfms-logical-formalism on the grounds that the model theory adequately addresses this issue.
Currently: Closed (response)
Raised Wed, 04 Oct 2000 by Pierre-Antoine CHAMPIN
Summary: what is the difference between writing <Description ID="bar"> and <Description about="#bar">? Why is ID needed?
Further Discussion:
Resolution: On 14th December, the RDFCore WG resolved:
The new syntax WD resolves this issue.
Test cases were also approved (though note that test 2 was not approved pending resolution of an internationalization issue)
Currently: for closed (response)
raised Mon, 04 Jun 2001 by Dan Connolly
Summary: An RDF processor would have to process sub-property relationships to correctly process rdf:aboutEach.
For example, consider using a subproperty of rdf:_2 to specify the second member
of a collection:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:ex="http://example/vocab#">
<r:Description r:about="#books"
xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<r:type r:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
<r:_1 r:resource="#book1" />
<ex:member2 r:resource="#book2" />
<r:_3 r:resource="#book3" />
</r:Description>
<rdf:Description rdf:aboutEach="#books">
<dc:rights xmlns:dc="http://purl.org/dc/elements/1.1/">all
mine!</dc:rights>
</rdf:Description>
<rdf:Description rdf:about="http://example/vocab#member2">
<rdfs:subPropertyOf
rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#_2"/>
</rdf:Description>
</rdf:RDF>
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.
Currently: closed (response)
Raised Tue, Aug 22 2000 by Stefan Kokkelink
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?
Resolution: On 11th January 2002, the RDFCore WG resolved:
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.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Jonathan Borden
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.
Further Discussion:
Resolution: On 11th January 2002 the RDFCore WG resolved:
The WG resolves to not change the algorithm for mapping qnames to uris and close this issue on the grounds:
1. Such a change would be a major change to the mapping of RDF/XML syntax to the model and would be beyond our charter.
2. It would cause the same RDF/XML to generate a different graph from existing versus revised implementations
3. Existing code may generate wrong (illegal) graphs for some RDF/XML.
Currently: closed (response)
raised Wed 21 Feb 2001 by Brian McBride
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.
For example, what triples does the following represent:
<rdf:Bag rdf:ID='bag'/> <rdf:li rdf:resource='http://foo/bag1'/> <rdf:li rdf:resource='http://foo/bag2'/> </rdf:Bag> <rdf:Description rdf:aboutEach='#bag'> <foo:bar rdf:ID='stmtId'>...</foo:bar> </rdf:Description>
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolves that this issue be closed on the grounds that with the removal of rdf:aboutEachPrefix and rdf:aboutEach there are no distributive referrants and the issue is mute.
Currently: closed (response)
raised Thu, 21 Dec 2000 by Bill de hOra
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.
Further Discussion:
Resolution: On 15th February 2002 the RDFCore WG resolved:
the WG resolves that this issue is addressed by the primer and that this issue be closed.
Currently: closed (response)
Raised Mon, Nov 22 1999 by Ron Daniel
Summary: The RDF Model and Syntax specification does not cover the nature of RDF graphs in its formal model.
See Also:
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.
Further Discussion:
Resolution: On 15th February 2002, the RDFCore WG resolved:
the WG resolve that the model theory is a formal description of the properties of an RDF graph and that this issue be closed.
Currently: closed (response)
raised ???, ?? ??? ???? by ??? ???
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.
See Also:
Resolution: On 15th February 2002, the RDFCore WG resolved:
that the proposed change would be a major change to the RDF specification and is out of scope for this WG.
Currently: closed
Raised Tue, 29 Feb 2000 by mailto:[email protected],
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:
Currently: closed (response)
Raised Tue, 29 Feb 2000 by mailto:[email protected],
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?
Further Discussion:
Resolution: At the 15th February 2002 telecon, the RDFCore WG:
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.
Currently: closed (response)
raised Sat, 08 Mar 2001 by Aaron Swartz
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:
<foo> <chocolateLover> <true> .
<foo> <rdf:chocolateHater> <true> .can be represented by
<foo> <rdf:type> <ChocolateLover> .
<foo> <rdf:type> <ChocolateHater> .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.
Currently: closed (response)
Raised Fri, Dec 31 1999 by Eric Hellman
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:
<rdf:Description> <foo:bar rdf:ID="foobar" rdf:resource="http://foobar"/> </rdf:Description>
is not legal. This can instead be written as:
<rdf:Description>
<foo:bar rdf:ID="foobar">
<rdf:Description rdf:resource="http://foobar"/>
</foo:bar>
</rdf:Description>
thus the same effect can be achieved, however the irregularity in the language may cause confusion.
Resolution:
At the RDFCore WG face to face meeting in February 2002, the WG decided:
<rdf:Description> <foo:bar rdf:ID="foo" rdf:resource="bar"/> </rdf:Description>
is legal.
This issue is now closed.
Currently: closed (response)
raised Mon, 12 Feb 2001 by Pierre-Antoine CHAMPIN
Summary: The Model and Syntax specification does not clearly specify which reified statements are put in which bag when nested description elements have bagID's.
For example, which reified statements should appear in which bag for the the following:
<rdf:Description about="a" bagID="bag1">
<some:prop rdf:ID="st1">
<rdf:Description about="b" bagID="bag2">
<some:otherProp rdf:ID="st2">
A literal
</some:otherProp>
</rdf:Description>
</some:prop>
</rdf:Description>
Resolution: The RDFCore WG has decided:
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.
Specifically:
<rdf:Description about="a" bagID="bag1">
<some:prop rdf:ID="st1">
<rdf:Description about="b" bagID="bag2">
<some:otherProp rdf:ID="st2">A literal</some:otherProp>
</rdf:Description>
</some:prop>
</rdf:Description>
generates two bags. Bag1 containts st1 only. Bag2 contains st2 only.
Currently: closed (response)
raised Thu, 14 Jun 2001 by Jeremy Carroll
Summary: Clarify the legality of the use of names from the RDF namespace, e.g. can rdf:Bag be used as a property or can rdf:Description be used as a property attribute etc.
Resolution: On 30th November 2001, the RDFCore WG:
- Resolves that the use of rdf:RDF, rdf:ID, rdf:about, rdf:resource, rdf:bagID, rdf:parseType, rdf:aboutEach and rdf:li except as reserved names as specified in the grammar is an error.
- resolves that test case http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/test005.rdf be obsoleted
- resolves that a copy of that test case be created as an error test
At the February face to face meeting, the WG futher resolved:
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.
And that specifically:
<rdf:Description>
<rdf:foo>foo</rdf:foo>
</rdf:Description>
is equivalent to:
_:a <rdf:foo> "foo" .
Currently: Closed (response1, response2)
Summary: A list of general editorial comments on the RDF Model and Syntax specification.
Further Discussion:
Resolution: The RDFCore WG resolved:
Given decision d-2002-02-25-8 [the M&S would be replaced], the editorial issues with M&S are now not relevant to the current document set and this issue be closed.
Status: closed
Raised Sat, 17 Feb 2001 by Dan Connolly
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.
At the February 2002 face to face meeting, the RDFCore WG resolved:
Currently: Closed (response)
or... "what is it that is identified?"
Raised Tue, 29 Feb 2000 by mailto:[email protected]
Summary: "In the RDF (model/syntax) spec a reference to a subtree of an XML document containing RDF is taken to be a reference to the RDF object." (TimBL)
see also: "how to address RDF fragement", rdf-comments query from mailto:[email protected]. The xml-uri archives also hold much discussion on overlapping themes.
Analysis: this detailed summary by Ralph Swick notes that...
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 [email protected] 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, [email protected] from March 2000: Re: Subclass of Thing/ Sat, 04 Mar 2000 00:24:21 GMT
Further Discussion:
Resolution: The RDFCore WG resolved:
that RDF uses URI's with fragment ID's to identify resources. This issue is now closed.
It also raised an action to draft text for the primer on th euse of fragment id's with appropriate warnings regarding their semantics and asked Dan Connolly to hightlight this issue with the TAG.
Currently: closed(response)
Summary: "This is a mess - it is in the syntax and not in the model. Should have used an RDF vocabulary for language. It should be removed from the syntax."
Raised Tue, 29 Feb 2000 by mailto:[email protected]
See also: issue rdfms-literalsubjects, which raises the problem of ascribing properties and attributes to RDF.
Resolution: The RDFCore WG resolved:
a literal consists of three components:
- A representation of the parseType, which is a single bit
- A language indicator which is a string as defined in XML
- A fully normalized UNICODE string.
The WG subsequently resolved that typed literals would not have a language tag.
Currently: closed (response)
raised Thu, 08 Mar 2001 by Dan Connolly
Summary: A statement with a parseType of 'Literal' has as its object an XML structure, not a simple string. For example, the first character of the literal <foo>bar</foo> is not '<'.
Background:
Resolution: The RDFCore WG resolved 26 Feb 2002:
a literal consists of three components:
(notice of 26 Feb 2002 decision)
Subsequently the RDFCore WG resolved to treat XML Literals as a datatype.
During review of the Jan 2003 last call drafts, the RDFCore WG resolved 9 May 2003 to refine the structure of XML literals:
Language tag is simply dropped from all typed literals including rdf:XMLLiteral
The WG also decided that normalization of the string component was not required.
In preparation for that decision, the WG considered
four different designs, for the result of an
rdf:parseType="Literal":
Members of the WG have argued that:
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.
To summarize:
|
Special untyped literal |
Special typed literal |
Wrapped normal typed literal |
Normal typed literal no wrapping |
|
|---|---|---|---|---|
|
use a generic datatyping mechanism |
No | No | Yes | Yes |
|
XML syntax ... arbitrary choice |
No | No | Yes | Yes |
|
[permit] non-built-in datatype [like] rdf:XMLLiteral. |
No | No | Yes | Yes |
|
[avoid] an RDF-specific solution [to the problem of] XML [...] context |
Yes | Yes | No | Yes |
|
[avoid] smack[ing] of being a hack |
Yes | No | No | Yes |
|
xml:lang [is] inherited |
Yes | Yes | Yes | No |
|
Works with OWL Candidate Rec |
No | No | Yes | Yes |
Raised Wed, Sep 06 by [email protected].
Summary:
"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. " [email protected] 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:
Resource Description Framework (RDF) Model and Syntax Specification Wed, 24 Feb 1999 14:45:07 GMT
- 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.
Resolution: The RDFCore WG resolved:
<stmt1> <rdf:type> <rdf:Statement> . <stmt1> <rdf:subject> <subject> . <stmt1> <rdf:predicate> <predicate> . <stmt1> <rdf:object> <object> . <stmt2> <rdf:type> <rdf:Statement> . <stmt2> <rdf:subject> <subject> . <stmt2> <rdf:predicate> <predicate> . <stmt2> <rdf:object> <object> . <stmt1> <property> <foo> .does not entail:
<stmt2> <property> <foo> .
Currently: closed (response)
Raised Fri, 12 Jan 2001 by Peter F. Patel-Schneider
Summary: The lack of a formal semantics for RDF and RDFS make it difficult to construct systems with formal semantics on top of it.
The original message raising this issue lists a number of specific questions:
Resolution: The RDFCore WG resolved:
that the model theory defines formal semantics for RDF and that this issue be closed.
Currently: closed (response)
raised Mon, 05 Mar 2001 by Stefan Kokkelink
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.
For example, How should the following be processed?
<?xml version="1.0" ?>
<rdf:RDF xmlns="http://www.w3.org/HTML"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:html="http://NoHTML"
xmlns:my="http://my">
<rdf:Description about="John_Smith">
<my:Name rdf:parseType="Literal">
<html:h1>
<b>John</b>
</html:h1>
</my:Name>
</rdf:Description>
</rdf:RDF>
CARA creates the following literal respecting the given namespace information:
l('<html:h1 xmlns:html="http://NoHTML">
<b xmlns="http://www.w3.org/HTML">John</b>
</html:h1>')
Resolution: The RDFCore WG resolved:
- 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.
Currently: closed (response)
raised Wed, 09 May 2001 by Ron Daniel
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:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/" xml:base="http://example.org/dir/file"> <eg:type rdf:about="" /> </rdf:RDF>is equivalent to:
<http://example.org/dir/file> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/type> .
Currently: closed (response)
raised Wed, 14 Jun 2000 by Andy Powell
Summary: Concern that the RDFS CR offers no guidance about the mime type to be assigned to RDF Schema documents, or to RDF/XML files in general.
Notes: this concern also applies to the RDF Model and Syntax specification, and to mixed-namespace XML documents in the general case. See also XML mime type internet drafts.
Further Discussion:
Resolution: On 5th April 2002, the RDFCore WG approved initial submission of an internet draft for the registration of an RDF mime type and resolved to close this issue.
Currently: closed (response)
Raised Mon, 01 Oct 2001 by Jeremy Carroll
Summary:Does the treatment of literals conform to charmod ?
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.
Currently: closed (response)
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..
Currently: closed
raised Wed 21 Feb 2001 by Aaron Swartz
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.
Resolution: On 17th June 2002 the RDFCore WG resolved:
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
Currently: closed (response)
Raised 25th Apr 2002
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.
Resolution: On 17th June 2002, the RDFCore WG resolved:
to modify the existing RDF and RDFS namespaces rather than create new ones and seek implementor feedback on this decision.
Currently: closed
raised Fri, 16 Feb 2001 by Graham Wideman
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
Currently: closed (response)
This is list of minor editorial issues.
Further Discussion:
Resolution: On 17th June 2002, the RDFCore WG agreed:
to defer schema document editorial issues to the editor and close rdfs-editorial.
Currently: closed
Raised Mon, 01 Oct 2001 by Jeremy Carroll
Summary: Does the treatment of uri-references conform with charmod?
Resolution: On 26th April 2002 the RDFCore WG approved a number of test cases and resolved to close this issue.
Currently: closed
raised Wed, 26 Jul 2000 by Dan Connolly
Summary: There is a problem with the definition of the character encoding of the online RDF Schema which can cause XML parsers to fail to parse it.
Resolution: The RDFCore WG updated the file and resolved to close the issue.
Currently: closed (response)
raised in RDFCore WG discussions
Summary: There is a need for a super property of all the container membership properties
Resolution: On the 9th April 2002, the RDFCore WG resolved that a super property for all the container membership properties would be defined.
Currently: closed
raised Thu, 20th Apr 2000 by Francois Leygues
Further Discussion:
Resolution: On the 9th April 2002, the RDFCore WG resolved:
- Expressing such a constraint is beyond the scope of RDFS. Such functionality belongs with more powerful ontology languages such as daml oil and owl.
- The WG notes that DAML OIL can express this constraint as described here.
- The WG closes this issue
Currently: closed (response)
raised Wed, 14 Jun 2000 by Michel Klein
Summary: Can an instance of the Property class have a subClassOf property? What does this mean?
Resolution: On 9th April 2002, the RDFCore WG resolved:
- an instance of the Property class may have an rdfs:subClassOf property
- the meaning of such a property is defined by the model theory
- this issue be closed
Currently: closed (response)
Raised 25th Apr 2002 by Dan Connolly and Peter F. Patel Schneider
Summary: Model and Syntax says that a container can't have duplicate member properties.
Discussion: Model and Syntax, in section 5 states:
For a single collection resource there may be at most one triple whose predicate is any given element of Ord and the elements of Ord must be used in sequence starting with RDF:_1
This gives rise to the following test case. Is the following legal RDF?
<rdf:Bag> <rdf:_1 rdf:resource="ex:first" /> <rdf:_2 rdf:resource="ex:second" /> <rdf:_1 rdf:resource="ex:other-first" /> </rdf:Bag>
Resolution: On 3rd May 2002, the RDFCore WG resolved:
<rdf:Bag rdf:about="http://example.org/foo">
<rdf:_1 rdf:resource="http://example.org/a" />
<rdf:_1 rdf:resource="http://example.org/b" />
</rdf:Bag>is syntactically legal RDF.
Currently: closed (response)
raised Wed 20 Dec 2000 by Ann Navarro
Summary: The RDF FAQ suggests how RDF meta data might be included in HTML. The suggested approach is fails HTML 4.01 and XHTML validation.
Further Discussion:
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.
Currently: closed (response)
raised Thu, 22 Feb 2001 by Dan Connolly
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.
see also: rdf-containers-otherapproaches
Resolution: On 31st May 2002, the RDFCore WG resolved:
Currently: closed (response)
raised Mon, 1st May 2000 by Daniel Liplin
Further Discussion:
Resolution: On 11 Oct 2002 the RDFCore WG resolved:
Currently: closed (response)
The resolution of msg 0098 with all options, and fix from GK.
The WG expended considerable time and energy trying to find a consensus datatyping solution. The problem is that there are ultimately irreconcilable requirements:
_:a eg:prop1 "10" .
_:b eg:prop2 "10" .
entails
_:a eg:prop1 _:l .
_:b eg:prop2 _:l .
rdfs:range, e.g.:
_:a eg:prop1 "10" .
eg:prop1 rdfs:range xsd:decimal .
entails
_:a eg:prop1 "10"^^xsd:decimal .
_:a eg:prop1 "10" .
_:b eg:prop2 "10" .
entails
_:a eg:prop1 _:l .
_:b eg:prop2 _:l .
But adding:
eg:prop1 rdfs:range xsd:decimal .
eg:prop2 rdfs:range xsd:string .
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.
This section had become out of date and has been obsoleted.
---- $Log: Overview.html,v $ Revision 1.227 2005/12/15 14:59:50 connolly fixed markup bugs; missing tags and punctuation Revision 1.226 2004/01/05 11:42:02 bmcbride Updated mime-types-... to refer to rdfms assertion and to WEBONT issue. Updated rdfms-assertion to refer to tag issue and sw meaning forum discussion Revision 1.225 2003/11/13 17:36:37 bmcbride fixed type Revision 1.217 2003/11/12 22:58:21 connolly elaborated rationale for literal structure decision Revision 1.216 2003/11/11 19:59:19 bmcbride noted withdrawl of pfps objection on the completeness of the closure rules. added section on objections at request to advance to PR Revision 1.215 2003/11/06 18:15:03 bmcbride added seeAlso to 2nd last call comments Revision 1.212 2003/10/30 15:53:25 bmcbride Added to #rdfs-lang-vocab that consideration should also be given to representing language information about literals in the triple structure. Revision 1.211 2003/10/10 11:03:48 bmcbride removed commnent in the status section about internal broken links - they all appear to be fixed now. Revision 1.206 2003/10/09 14:01:34 bmcbride fixed validation errors Revision 1.204 2003/10/09 13:10:15 bmcbride fixed some broken anchors Revision 1.202 2003/10/08 11:14:41 bmcbride Fixed missing fragment anchors Add rdfms-syntax-incomplete to list of postponed issues. Revision 1.201 2003/10/07 14:43:23 bmcbride Removed pfps objection on NFC per http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0025.html Revision 1.200 2003/10/06 16:19:42 bmcbride add link to xml schema ig in xml schema objection. Revision 1.199 2003/10/06 16:17:26 bmcbride added XML schema objection. Revision 1.198 2003/10/03 11:17:19 bmcbride linked rdfs-xml-schema-datatypes to objections from Mike Dean and Aaron Swartz. Revision 1.196 2003/10/03 10:36:25 bmcbride Created objection section and merged in objections document. Revision 1.195 2003/10/03 10:25:26 bmcbride Obsoleted the attention developers section. Revision 1.194 2003/09/30 13:47:10 bmcbride added issue rdf-mapping-lists-and-containers Revision 1.193 2003/07/21 11:11:40 bmcbride corrected minor typo Revision 1.191 2003/05/15 17:07:06 bmcbride fixed typo Revision 1.190 2003/05/15 17:04:06 bmcbride updated resolution of literal-is-xml-structure Revision 1.189 2003/05/08 13:17:36 bmcbride Added rdfs-fyi Revision 1.188 2003/05/07 20:25:01 bmcbride per his request, added link under rdfms-validating-embedded-rdf to Mark Butler's response to the postponement decision. Revision 1.187 2003/04/29 18:48:33 bmcbride Updated rdfms-validating-embedded-rdf to link also to last call comments from the xml schema group. Revision 1.186 2003/04/09 09:31:02 bmcbride rename rdfs-lang-uris to rdfs-lang-vocab Revision 1.182 2003/03/27 12:06:15 bmcbride correcting broken frag id's Revision 1.177 2003/03/27 09:28:38 bmcbride fixed some of the broken fragments Revision 1.176 2003/03/13 17:36:15 bmcbride Fixed some bad frag id's Revision 1.175 2003/03/13 17:29:18 bmcbride Moved rdfms-assertion to postponed Moved datatypes to closed Revision 1.174 2002/10/11 16:03:17 connolly updated issue syntax-incomplete w.r.t. 26 July decision Revision 1.173 2002/09/28 11:00:45 bmcbride refined text of #rdf-embedded Revision 1.171 2002/09/18 07:57:30 bmcbride moved containers-other-approaches to correct section Revision 1.170 2002/08/29 17:46:40 bmcbride minor editorial correction Revision 1.166 2002/08/19 15:30:00 bmcbride Minor editorial corrections Revision 1.162 2002/07/04 13:59:54 bmcbride added see also links between rdfms-containers-other-approaches and rdfms-seq-representation Revision 1.161 2002/05/02 19:14:32 bmcbride Added new issue:rdfms-duplicate-member-props Revision 1.160 2002/04/30 00:43:58 em fixing various issue references to make various rdf core docs pubrules valid Revision 1.159 2002/04/29 17:32:57 bmcbride Updated text of rdfms-para196 Revision 1.158 2002/04/29 15:46:16 danbri added html anchor Revision 1.157 2002/04/29 15:42:29 danbri added placeholder for a new issue, rdfms-parag196 Revision 1.156 2002/04/25 12:53:44 bmcbride corrected bad link Revision 1.154 2002/04/08 14:12:58 bmcbride closed rdf-charmod-literals Revision 1.153 2002/04/08 13:09:11 bmcbride closed mime-types-for-rdf-docs Revision 1.152 2002/04/04 17:18:32 bmcbride added new issue: rdfs-container-membership-superProperty Revision 1.150 2002/03/25 16:57:47 bmcbride closed xml-base and literal-namespaces issues Revision 1.149 2002/03/11 15:55:56 bmcbride Fixed typo Revision 1.143 2002/02/24 10:39:15 bmcbride tidied xhtml Revision 1.142 2002/02/24 09:44:41 bmcbride moved literals-as-subjects to postponed list from closed list Revision 1.140 2002/02/18 18:01:48 bmcbride correct xhtml Revision 1.139 2002/02/18 17:44:09 bmcbride closed Issues: rdfms-propElt-id-with-dr rdf-terminologicus rdfms-graph rdfms-literals-as-resources rdfms-literalsubjects rdfms-uri-substructure rdfms-boolean-valued-properties Revision 1.138 2002/01/23 08:58:36 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.137 2002/01/14 14:38:06 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.136 2001/12/20 21:36:29 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.127 2001/12/11 16:24:01 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.125 2001/11/23 13:50:05 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.121 2001/11/20 19:40:39 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.120 2001/11/19 15:38:45 bmcbride bmcbride) Changed through Jigsaw. Revision 1.119 2001/11/18 15:58:47 bmcbride bmcbride) Changed through Jigsaw. Revision 1.116 2001/11/12 16:23:39 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.115 2001/11/07 22:01:05 bmcbride bmcbride) Changed through Jigsaw. Revision 1.114 2001/11/05 16:35:41 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.110 2001/11/01 15:18:58 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.101 2001/10/16 19:23:36 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.99 2001/10/11 11:58:40 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.98 2001/10/10 15:31:46 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.92 2001/09/11 20:34:23 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.89 2001/09/10 10:42:18 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.88 2001/09/03 17:13:21 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.87 2001/08/30 12:06:23 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.85 2001/08/29 17:55:54 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.84 2001/08/28 14:01:23 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.80 2001/08/21 14:24:33 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.77 2001/08/20 18:54:37 barstow Added names/tags for the Table of Contents and Attention Developers sections so they can be addressed. Revision 1.76 2001/08/16 14:20:35 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.75 2001/08/13 13:33:03 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.74 2001/08/06 12:12:50 barstow Fixed typo: the issue is "id-with-dr", not "id-in-dr". Revision 1.73 2001/07/27 17:07:21 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.72 2001/07/16 16:26:53 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.69 2001/07/05 16:37:51 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.68 2001/07/02 12:42:30 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.66 2001/06/27 16:09:09 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.65 2001/06/25 12:47:03 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.63 2001/06/22 07:08:31 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.60 2001/06/20 14:34:54 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.59 2001/06/11 16:26:49 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.58 2001/06/11 16:24:00 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.57 2001/06/08 10:54:48 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.54 2001/06/07 12:37:29 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.51 2001/06/05 16:24:05 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.50 2001/06/01 09:46:54 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.49 2001/05/31 21:13:21 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.42 2001/05/03 02:04:53 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.41 2001/04/27 09:09:51 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.40 2001/04/26 21:55:05 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.39 2001/04/24 16:16:57 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.38 2001/04/23 11:30:37 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.37 2001/04/18 17:13:11 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.36 2001/04/16 16:18:55 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.28 2001/04/13 11:42:02 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.26 2001/03/20 11:23:36 bmcbride (bmcbride) Changed through Jigsaw. Revision 1.21 2001/02/09 12:34:42 danbri tidy'd xhtml
Revision 1.20 2001/02/09 12:31:36 danbri
checking in changes by brian
Revision 1.19 2000/10/12 22:27:47 danbri xhtml valid again. Revision 1.18 2000/10/12 22:26:01 danbri fixed ToC Revision 1.17 2000/10/12 22:24:01 danbri added rdf:resource writeup (from Lee Jonas) Revision 1.16 2000/10/12 22:12:56 danbri fixed up ToC Revision 1.15 2000/10/12 22:10:40 danbri added more issues, link to brian's excellent overview of discussions etc Revision 1.14 2000/10/12 21:19:58 danbri linking new container issues from table of contents Revision 1.13 2000/10/12 21:15:07 danbri escaped quoted XML markup Revision 1.12 2000/10/12 21:13:30 danbri added a couple of container-related issues from Graham Klyne, 2000-09-06 msg. Revision 1.11 2000/10/12 20:48:32 danbri created natural language labels for each issue, replacing the original meaningless numeric identifiers (though leaving anchor targets in place to preserve old links). Revision 1.10 2000/10/12 17:43:09 danbri added a little clarification text under 'Context'. Revision 1.9 2000/10/12 17:39:54 danbri added logo Revision 1.8 2000/09/06 19:00:31 danbri added rdfms006, statements repeated with same p/s/o issue. still todo: http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0036.html http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0037.html Revision 1.7 2000/09/06 18:07:39 danbri Added more detail to 'semantics of #' rdf issue. Revision 1.6 2000/09/05 12:58:03 danbri Added link to Stefan's RDF proposed updates page, and CVS changes log.