[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]