Ok, this should be a quick one.
We have interpretations for
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:random="http://random.ioctl.org/#">
<rdf:Description>
<random:someProperty rdf:resource="http://random.ioctl.org/#foo" />
</rdf:Description>
</rdf:RDF>
...which pretty clearly sticks a resource at the sharp end of the
property arc. Similarly, we also have
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:random="http://random.ioctl.org/#">
<random:Objecttype>
<random:someProperty rdf:parseType="Literal" />
</random:Objecttype>
</rdf:RDF>
...which fairly unambiguously makes the value on the end of the arc a
literal null string. The question is what to do with:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:random="http://random.ioctl.org/#">
<random:Objecttype>
<random:someProperty/>
</random:Objecttype>
</rdf:RDF>
There seem to be three options available:
- explicitly forbid this
- interpret it as having an anonymous resource as the value of the
property
- interpret it as having the null literal as the value of the property,
as already suggested by Jos de Roo.
(in the last two cases, we may choose to deprecate this form)
There are arguments of ostensibly equal value for choosing either of
the latter two options; I'd lean towards Jos' point of view: that the
interpretation of
<random:someProperty/>
be a property arc pointing to the null literal; to generate an anonymous
resource without other properties, we can use
<random:someProperty rdf:parseType="Resource"/>
- which is what I'd propose, together with weakly deprecating the
undifferentiated use in emitted RDF (see below for reasons).
There's a twist, by the way: if we have a parser with some schema
knowledge and we have the rdfs:range of random:someProperty defined to
be some subclass of rdf:Literal, it makes sense to use the literal
interpretation. Similarly, if the rdfs:range of random:someProperty is
not a literal class, then we might choose to use the "it's an anonymous
resource" interpretation. Such behaviour requires the parser to have
some knowledge of the schemas in use - I'm not aware of any from the
current crop that do this sort of thing; in the future, this might be
the "right" interpretation of this construct. Thus, I'd be inclined to
recommend that this form of a property be emitted with a parseType
attribute.
jan
--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
stty intr ^m