Re: [office-metadata] m:data-value / m:data-type only on anonymous RDF node?

[Elias Torres <eliast@us.ibm.com>]

I'm drowning in work, but I have stuff to say about this. That's all I can
say for now.

Svante, could you call me later today? email me for the phone number.

-Elias

Svante.Schubert@Sun.COM wrote on 05/09/2007 10:52:09 AM:

> John F. Madden, MD, PhD wrote:
> > I agree this is confusing.
> >
> > It may be clarifying to consider the implementation in the RDFa
> > specification.
> >
> > In RDFa, they actually have two different versions of the one
> > attribute that we call "property".
> >
> > If the "property" has an object that is something other than a URI,
> > then RDFa uses the attribute "property".
> > If the "property" has an object that is a URI, then RDFa uses the
> > attribute "rel".
> In RDFa they have no other opportunity as to describe all RDF statements
> in content.
> In the OpenDocument format I favor to keep as much metadata in the
> metadata files.
>
> If I remember correctly was the original idea about
> m:data-type/m:data-value in the content that the RDF literal being
> expressed by m:about and m:property might need further rdf statements as
> it is hardly  referable from the RDF/XML file.
> >
> > So RDFa would represent the following two triples:
> >
> >     ex:aDocument dc:author "Svante Schubert"^^rdf:XMLLiteral
> > as      <element about="ex:aDocument" property="dc:author">Svante
> > Schubert</element>
> >
> >         whereas
> >
> >     ex:aDocument rdf:type    ex:ChangeProposal    as <element
> > about'"ex:aDocument" rel:"rdf:type" href="ex:ChangeProposal"/>
> >
> >
> > When using "property", RDFa does give the option to override the
> > default datatyping of a string (by default as rdf:XMLLiteral) by use
> > of a "datatype" attribute:
> >
> >     ex:aDocument dc:date "20070101"^^xsd:Date       would be
> > <element about="ex:aDocument property="dc:date"
> > datatype="xsd:Date>20070101</element>
> >
> >
> > So..........conclusion:
> >
> >  I think that we may be trying to do the same thing here---specify
> > some metadata about the OBJECT of the triple.
> >
> > However, since we only have the m:property element, we need to
> > consider three cases:
> >
> >     (1) the object is a URI
> Is there a benefit, when not keeping these kind of statements in RDF/XML?
> >     (2) the object is a typed literal
> How is the object literal being typed? When the literal can never be the
> subject? (Aside of the following notation: 20070101"^^xsd:Date)
> >     (3) the object is an "untyped" literal, i.e. an rdf:XMLLiteral (or
> > perhaps, if we like, an rdf:literal, or even an xsd:string --whatever
> > we define as our "default).
> For me a string as default seems fine.
> >
> > Any parser that parses ODF in-content metadata is going to have to
> > decide which of these three cases obtains, in order to parse the
> > metadata properly.
> >
> >
> > John
> >
> >
> >
> >
> >
> >
> >
> >
> > On May 9, 2007, at 9:57 AM, Svante Schubert wrote:
> >
> >> The question is what is the RDF statement m:data-value and
> >> m:data-type are part of?
> >>
> >> As a reminder the optional attributes m:data-value and m:data-type
> >> can occur on every element, where m:about/m:property can occur as
> >> well (therefore not on text:meta-field).
> >>
> >> <attribute name="m:data-type">
> >>    <data type="anyURI"/>
> >> </attribute>
> >> <attribute name="m:data-value">
> >>    <ref name="string"/>
> >> </attribute>
> >>
> >> Each of them is an RDF predicate, the RDF object is anyURI in case of
> >> m:data-type and a string in case of m:data-value.
> >> But what is the RDF subject, it can not be the literal (element
> >> content) itself, as a literal is never a RDF subject.
> >>
> >> I would think it is the element, which is anonymous in RDF (without
> >> an IRI).
> >>
> >> In this case, without using an xml:id to bind the OpenDocument
> >> element via the meta manifest to an IRI, the data-type and data-value
> >> will never be part of the larger RDF graph of the document.
> >>
> >> Is this correct?
> >>
> >> Svante
> >>
> >>
> >