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] suggestions on identifying nodes, namespace



Svante.Schubert@Sun.COM wrote on 02/22/2007 01:26:12 PM:

> Hi Bruce,
>
> many thanks for catching this up.
> For me the ID with it's binding mechanism is the most important thing to
> decide. I would like to focus on this as a next step, although other
> things, might be interesting, too.
>
> I would even separate the usage of a meta:class attribute from this
> discussion, as Elias stated in the call grouping might be done in
> RDF/XML group/bag and is therefore - although possibly welcome - an
> additional option.
>
> For now I would like to give examples why I think a unique ID is
necessary:
> Imagine there are dozen identical tables in a document. In our earlier
> scenario we would have given them the same meta:id. But when any RDF
> application later during the existence of the document, wants to add
> metadata only to one of the tables (for example to add a running /
> counting number or to express the one, that is first seen by the reader)
> there would be no way, but to change the ID, which would raise
> consistency problems, possibly even unsolvable from the application as
> it would be linked from external documents.

+1 I think ID should be unique.

>
>
> Bruce D'Arcus wrote:
> > So based on conversation today, here's what I'd suggest:
> >
> > 1) use xml:id to identify document elements
> We have here already a decision to be made. Do we use xml:id or do we
> use meta:id and require an IRI for RDF way of binding?
> I earlier preferred the IRI binding, but I do not like to have two
> different types of IDs in the content. xml:id and meta:id, which as
> additional to xml:id the restriction to be an IRI.
> If we use a xml:id, we have to solve the problem of relative links, once
> the validation of an RDF/XML with relative provided a deprecation
> warning using
>
> http://www.w3.org/RDF/Validator/
>
> Now the relative link is (incorrectly) resolved by exchanging '../' with
> 'http://www.w3.org/RDF/Validator/' (already reported).
>
> Elias once came up with the idea of using a xml:base URL, which might be
> theoretically different for every RDF/XML file of the package.
>
> Furthermore to make things for RDF comparable we suggested to use
owl:sameAs
> http://www.w3.org/TR/owl-ref/#sameAs-def
>
> Any further details I have not mentioned that might help us to find a
> decision?

I think xml:id="foo" resolving to <content.xml#foo> will be ok. However, we
need a way to make it absolute for when metadata needs to be moved across
documents. I'd agree that having two id elements might be too confusing and
would not get too much traction.

-Elias

>
> Bests,
> Svante.
>
> >
> > The one issue I think we'd want to resolve is whether we want to use
> > existing name attributes (for tables and such) to achieve the same
thing.
> >
> > Clarification: Elias emphasized that there are ways other than using
> > identifiers to group items with common properties. The obvious one is
> > to assign them an rdf:type, which can be annoted with additional
> > properties.
> >
> > So from the model perspective, you have two tables: with xml:id or
> > table-name attribute of "table-1" and "table-2". Triples are:
> >
> > <[base-uri]table-1> rdf:type <http://ex.net/SalaryTable> .
> >
> > <[base-uri]table-2> rdf:type <http://ex.net/SalaryTable> .
> >
> > ... and then:
> >
> > <http://ex.net/SalaryTable> dc:description "Shows annual salaries."
> >
> > 2) move all of the metadata attributes -- property, resource, about,
> > value, data-type (I don't remember what they last few are precisely)
> > -- into the meta prefix ODF namespace.
> >
> > Bruce
> >



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