Re: Outstanding Issues

On 2002-02-11 17:28, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:

[perhaps these should each be in their own thread?]

> rdfms-xmllang: Why isn't xml:lang information represented within the RDF data
> model? 
> 
> This was put on hold whilst we looked at datatypes.  Model and Syntax says
> that lang is part of the literal; that no triples are generated for an
> xml:lang.  We can choose to stick with that or change it.  Does anyone have a
> compelling reason to change it?

I think it should not be changed, but the verbage could be clarified.

The xml:lang attribute exists for the benefit of XML applications
(e.g. an RDF parser) not RDF applications (e.g. an RDF query engine)
and therefore it is reasonable that it have no representation in
the graph (no triples generated). An XML application is free to
select or omit elements based on the xml:lang attribute -- but
since that is not part of the needed functionality of most (any?)
RDF parsers, the attribute simply has no effect.

If individuals wish to qualify resources by language value, in a
way that will affect queries and other graph-based operations,
then they should do so in a way that is meaningful to RDF
applications.

E.g.

   xxx ex:keyword _:1 .
   _:1 rdf:value "pan" .
   _:1 xml:lang _:2 .
   _:2 rdf:value "en" .
   _:2 rdf:dtype xsd:lang .

Note that _:2 is a datatyped literal but _:1 is simply
a qualified literal (qualified for language). Note also
the relationship between the property xml:lang and the
datatype xsd:lang.

That said, the M&S view that the language is "part of" the
literal is not quite right, and probably should be adjusted
(or removed), in that, as with datatyping, language is a
property of the occurrence (context) of the literal
and not the literal itself. And especially since literals are
now tidy, an application shouldn't attach context specific
properties such as language to globally shared literal nodes.

> rdfms-literal-is-xml-structure : A literal containing XML markup is not a
> simple string, but is an XML structure.
> 
> This issue was put on hold pending the outcome of the datatypes discussion.  I
> suggest we are far enough along on datatypes to bring this one back.

I propose that we treat XML literals just like datatyped literals. The
complex document type is similar to a datatype where the members of the
lexical space are XML instances and the members of the value space are
infoset instances.

Thus, one can define the type of an XML literal just like one would define
the type of an integer literal, and an application would know the context
(doctype) within which that literal would map to an infoset for
interpretation.

E.g.

  xxx ex:ContactInfo _:1 .
  _:1 rdf:value "<bCard><name>...<email>...<phone>...</bCard>" .
  _:1 rdf:dtype foo:BusinessCard .

It is not for RDF to either constrain, define, nor provide access to the
internal structure of any typed literal, XML literals included.

Eh?


> rdfms-replace-value: Suggestion that the rdf:value property be replaced by
> rdf:toString.
> 
> Issue modified to clarify the meaning of rdf:value.
> 
> Datatypes is considering using rdf:value in a way that conflicts with examples
> in M&S.  Data types should use a different property to avoid clashes with
> existing usage.  rdf:value has no model theoretic meaning; any interpretation
> of it is application specific.

One advantage of having a dedicated property other than rdf:value
is that it makes the interpretation of the doublet idiom that more
reliable, as the only place it would be used would be for datatyping.

E.g.

   _:1 rdf:lform "50" .
   _:1 rdf:dtype xsd:integer .

where 'lform' is short for lexical form.

> rdfms-seq-representation: The ordinal property representation of containers
> does not support recursive processing of containers in languages such as
> Prolog.
> 
> Hmmm.  Anyone got a proposal for fixing this?

Would this be helped by having a generic container membership property?

> rdfms-xml-literal-namespaces: How should a parser process namspaces in a
> literal which is XML markup?
> 
> This has been on hold pending datatypes outcome.  Time to bring back and
> resolve.

It shouldn't. Literals are opaque to RDF. Just as are URIrefs.

> rdf-charmod-literals: Does the treatment of literals conform to charmod ?
> 
> We need an owner to check this.
> 
> rdf-charmod-uris: Does the treatment of uris conform to charmod ?
> 
> We need an owner to check this

I'll check these two, if noone has beaten me to it already.

I trust that no'one has begun editing the actual M&S, and
that we simply have to be sure it includes the neccessary
conformance statements per section 2 of charmod?

> RDF Schema Issues
> ·       ·       rdfs-constraining-containers: Should it be possible to
> constrain the members of a container to be of a given type?

It seems to me that a range of a property does not apply
to the members of a container -- particularly because we
may wish to constrain a property to a particular container
type. 

Rather, perhaps we should allow rdfs:range to be defined
for container classes, to specify indirectly the range
of its generic membership properties within the context
of that container type.

E.g.

  ex:StudentBody rdfs:subClassOf rdf:Bag .
  ex:students rdfs:range ex:StudentBody .
  ex:StudentBody rdfs:range ex:Student .

Eh?


> ·       ·       rdfs-isDefinedBy-semantics: Must the value of an
> rdfs:isDefinedBy property be a schema?

I think it's too late to impose such a requirement.

Better to introduce something akin to what is used by XML Schema,
such as rdfs:schema.

Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 11 February 2002 11:41:21 UTC