OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Metadata text fields


Svante.Schubert@Sun.COM wrote on 02/22/2007 01:17:46 PM:

>
>
> Bruce D'Arcus wrote:
> >
> > On Feb 22, 2007, at 12:31 PM, Svante Schubert wrote:
> >
> > ...
> >
> >>>> This plug-in has furthermore the responsibility to keep the literal
> >>>> consistent with further metadata in the document (e.g. RDF/XML).
> >>>
> >>> This is where the confusion keeps coming in. There's no need to be
> >>> "consistent" here because the in-content text *is* the literal.
> >>> There's nothing to be consistent with.
> >> Unfortunately there is no guarantee that the RDF statement - where
> >> the literal is part as the RDF object - is unique in-content only.
> >> Aside of an usage in RDF/XML, there might be even the same in-content
> >> RDF statement a couple of times in the document. I would
> >> optimistically assume that if you change one, you change them all.
> >
> > I see what you mean now.
> >
> > Here's the thing: we cannot worry about this.
> >
> > Consider this example:
> >
> > <span about="urn:uuid:2387832787283" property="ex:tag">foo</span>
> > <span about="urn:uuid:2387832787283" property="ex:tag">bar</span>
> >
> > Are these "inconsistent"? Answer: only if we assume there can be only
> > one ex:tag property for a resource.
> >
> > So in essence, the answer is no, they aren't: they are two separate
> > statements.
> >
> > ...
>
> Exactly, it depends on the vocabulary being used. Therefore the only
> one, who the grammar knows and might keep consistency correctly is the
> RDF application (plug-in).



Svante, RDF is specifically designed for flexibility. Unless a plugin can
stop other plugins from adding statements to the ODF package, the plugin
can't guarantee what you are looking for. So if we limit content
attributes, I can still break your vocabulary (not grammar) via the
RDF/XML.



> >
> >>> ... have one new field whose job it is to display information about
> >>> *resources*.
> >>>
> >>> I want to say in my document that Patrick is the author, but I have
> >>> Patrick vCard record already in RDF/XML in the package, so I do
> >>> something like:
> >>>
> >>> <meta:field
> >>>     meta:about="urn:uuid:8134713815475740574" <!-- document URI -->
> >>>     meta:property="dc:creator"
> >>>     meta:resource="http://ex.net/people#patrick";>Patrick
> >>> Durusau</mta:field>
> >> Can you give me the RDF triples you are telling here and do you refer
> >> to the RDF/XML spec when you talk about a resource? Any link?
> >> Would not be one triple sufficient for the beginning?
> >
> > Triple is:
> >
> > <urn:uuid:813471381547574057> dc:creator <http://ex.net/people#patrick>
.
> >
> Thanks. Isn't there a further RDF statement about the relation of the
> string 'Patrick Durusau' and some of the RDF IRIs?



The text node of the meta:field is there just for display as "a" plugin
generated it. We would assume that in the RDF/XML there was a triple:

<http://ex.net/people#patrick> dc:title "Patrick Durusau" .

Again, the meta:field could get away with just xml:id in my opinion. The
rest could be in the RDF/XML. I don't want to infer triples from it,
because it's not dependent on its content and since it'd only depend on the
3 attributes, there's no gain in using that to specify the full triple,
might as well do that in RDF/XML.


>
> Regards,
> Svante



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]