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] My Proposal Review



On Feb 21, 2007, at 5:03 PM, Elias Torres wrote:

> 1.2.2.
>
> """ When a text portion of the content is created from metadata or the 
> text
> portion is a metadata literal, which might reoccur in a RDF/XML file, 
> the
> text portion should handled by a metadata text field for reasons of 
> data
> integrity. """
>
> I really don't understand either of these scenarios.

Yes, this is confusing. I'd prefer us to distinguish between in-content 
literals (where the text is the object of the triple) and in-content 
resources (where the text is a *label* for the resource, and so without 
any formal meaning).

> This is where Svante
> had said meta:about and meta:property were being relegated to and now I
> read:
>
> """The optional attribute pair “rdf:about” and  rdf:property.
> rdf:about represents the RDF subject IRI of the RDF statement and
> “rdf:property” represents the RDF predicate IRI."""
>
> They are optional? What can we possibly use this
> meta:text-set-get-field-whatever if the attributes needed to construct 
> a
> triple are optional?

Yes, it makes no sense to have the attributes optional.

To go back top, I've posted a specific proposal on this in RNG. Let's 
just define two patterns in RNG:

meta-content-object-literal = meta-about, meta-property
meta-content-object-resource = meta-about, meta-property, meta-resource

Can we agree on that?

If yes, then we can move on and assess where those patterns ought to be 
allowed.

> """ “meta:value-type” and “meta:value” """
>
> value-type I'm assuming is analogous to meta:class discussed today in 
> the
> call. I think we don't need it (because we can specify that inside
> RDF/XML).

No, it's for data-typing.

> with the same reasoning meta:value is not needed either since we can 
> bind
> that in the RDF/XML file.

That makes sense.

> """“meta:impl”"""
>
> This should not be needed either. We need to push this back to the 
> RDF/XML.

The question I think Svante was worrying about here is, how does a 
plug-in know *which* fields (or other content) it is responsible for? 
In other words, what's the relationship between a specific in-content 
element, a plug-in, and the RDF/XML graph?

If we can do without encoding it in the content, good. Any ideas?

> """In case a text portion is autogenerated by the RDF plugin and shall
> therefore only be changed from the RDF plugin, the should be marked as 
> a
> metadata text field.
> is based on metadata and the text is autogenerated by the plugin take
> responsibility of the handling from the content, two additional 
> elements
> are provided: 'meta:text-get' and 'meta:text-set'."""
>
> I definitely need examples for this. If a text portion is 
> auto-generated by
> an RDF plugin then what is it exactly that we need to do?

This goes back to the distinction between literals and resources I 
think. Perhaps if we can clarify the language (and the schema details) 
first, we can solve these other details more easily.

Bruce



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