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: Revision and stable ids (was: Re: [office-metadata] Rought notes 14 March)


Patrick Durusau <patrick@durusau.net> wrote on 03/14/2007 12:05:47 PM:

> Guys,
>
> Rough notes from today attached.
>
>
> 3) Elias' UUID + URI idea
>
> Don't have clear proposal, yet. More fundamental question to ask -
> copy the file in the system (Svante) - if use xml:id and not full
> URIs, have to construct a URI, then next aspect is have to make a
> decision when the document is changed, does the metadata still apply?
>
> A lot of metadata is stable. That is not in the content. But what
> about things that point to an xml:id to infer something about the
> content.
>
> One approach, every element is a new element on each save.
>
> metadata attached by ID and when ID is changed, the metadata no
> longer applies, but if stays the same, it reattaches to the new ID.

I think the above set up the issue we are trying to resolve.

Basically:

<text:p xml:id="foo" meta:about="content.xml#foo"
 meta:property="bar">baz</text:p>

and ...

<rdf:Description rdf:about="content.xml#foo">
      <whatever/>
</rdf:Description>

What happens when 'baz' is changed to 'zab' e.g. something completely
unrelated. The problems are:

- Does both the in-content metadata and the package metadata apply?
- Should we clear/remove some/all metadata from either or both the content
and the package meta files?

>
> Florian, dynamic ids based on editing. Could additionally use this ID
> for kept always, even if the content changes.
>
> Elais - give it an id, and a revision attribute, just keep pumping
> the revision attribute.
>
> Svante - Michael said StarOffice had this but wasn't liked. But
> Svante likes it.
>
> Svante - When is metadata is being removed? We don't have to say how
> people attach metadata.
>
> Elais: should be using IRC with the conference call
>
> Elais: paragraph with xml:id and revision:id - then meta:property
> attributes don't apply to those ids, meta:about decides which one it
> applies to, either to revision or revision less URI. Then can figure
> out how to remove the metadata.
>
> Elias: should not cause any more privacy concerns than current
> collection of metadata.
>
> Document ID: Elais, when we make metadata statements, need stable
> meta:about, can generate a doc id every time you open it. On every
> edit, to generate a new ID.

Expanding on Florian's idea and rough ideas from last week's call we have
the following:

In the manifest we have two ids:

A stable (never changing) id, most likely a UUID for purposes of relating
documents to one another.

A revision id (another UUID) generated when the document opens and
available for minting new URIs, but only committed upon saving the
document.

Then all metadata statements must be made on absolute URIs, for example
instead of content.xml#foo:

We would use something like this in the meta:about for specific revision:

urn:tag:[stable-document-id],[revision-doc-id]:foo

or for non-revision specific

urn:tag:[stable-document-id]:foo

I would then infer that in-context metadata would only be used for
non-revision specific information.

<text:p xml:id="foo" meta:about="urn:tag:[stable-document-id]:foo"
 meta:property="bar">baz</text:p>

or

<text:field xml:id="salary"
meta:about="urn:tag:[stable-document-id]:salary"
 meta:property="ex:salary">1,000,000,000</text:field>

Any revision specific can be placed in the RDF/XML files themselves.

>
> See chat session:
>
> Svante: could put the metadata under revision control -

Svante also had a great idea. Why not just put all metadata under revision
control?

Let me simply this is a bit and see if I can flesh out his suggestion. If
we only had one metadata file then on every save we can generate
[revision-id]-meta.xml. Then we don't have to worry about building revision
specific IDs.

I think in general this is a good idea but still doesn't solve the problem:
which triples need to be removed from the graph upon committing a new
revision.

For example:

<content.xml#foo> dc:title "foo" .
 dc:author <#elias> .

<#elias> foaf:name "Elias Torres" .

If we changed the "foo" element, we should remove that I authored that
element, but removing my foaf:name? That might not be necessary, in fact
could be harmful to other applications.

I hate to mention this, but if we come up with a naming scheme for elements
in ODF (like the tag scheme I used) or through some API, all metadata
attached to specific revision gets placed in revision controlled (a single)
meta file. All else gets stored in as many indepenent non revision
controlled files like photo-meta.xml.

>
> Elias - good idea, how do we do things where we want it attached to
> the element?
>
> Elias: revision for all metadata - problem with not having only one
> file - but maybe can use that for in content attributes, extract
> RDF/XML out of the document and attach it to the metadata -
>
> Florian - sending change tracking on styles - no mechanism like that
> in RDF -

Florian, I'm not familiar with tried and tested revision mechanisms in or
not in RDF. Therefore my revision suggestions must be taken with that in
mind. However, I can show you a basic pattern in modelling in RDF. We can
either model the revision in our ontology (but this is *only* to the
resources that conform to the ontology) or we use an out of band mechanism
to achieve revisioning (like in our IBM system).

<#elias> ex:currentAddress [
  a foaf:Address ;
  foaf:state "MA" .
] ;

ex:previousAddress [
  a foaf:Address ;
  foaf:state "CT" .
] ;

ex:previousAddress [
  a foaf:Address ;
  foaf:state "FL" .
] ;

Basically our ontology has predicates specialized to indicate revisions or
older property values. We can make use of an RDF container to denote order
(like sequence or list), etc. However, if anything else was attached to
either <#elias> or any of the address blank nodes, there's no way to really
know whether something is just multi-valued or a different revisions. We
are depending on ex:previousAddress.

<#elias> ex:currentAddress [
  a foaf:Address ;
  foaf:state "MA" .
] ;
  foaf:phone "555-5555" .

The phone property is not under the revision modeling of our ex:* Ontology.
Therefore multiple foaf:phone can be interpreted as all active phones or
inactive, we don't know.

The other approach is the Named Graph approach.

In NG #1

<#elias> foaf:address [
  a foaf:Address ;
  foaf:state "FL" .
] ;

In NG #2

<#elias> foaf:address [
  a foaf:Address ;
  foaf:state "CT" .
] ;

In NG #3

<#elias> foaf:address [
  a foaf:Address ;
  foaf:state "MA" .
] ;

... and in some NG metadata (e.g. our manifest file)

we say (a simple pointer management):

<#stable-ng-id> ex:latestVersion <#ng3> ;
 ex:previousVersions ( <#ng2>, <#ng1> ) .

We can go all out and something like this (basically add more metadata
about each revision):

<#stable-ng-id> ex:latestVersion [
  a ex:Revision ;
  ex:graphURI <#ng3> ;
  dc:author "Elias Torres" ;
  dc:modified "2007-02-01" .
] ;

 ex:previousVersions (

  [
    a ex:Revision ;
    ex:graphURI <#ng2> ;
    dc:author "Elias Torres" ;
    dc:modified "2006-02-01" .
  ],

  [
    a ex:Revision ;
    ex:graphURI <#ng1> ;
    dc:author "Elias Torres" ;
    dc:modified "2005-02-01" .
  ],

 ) .

I hope all of this helps answer your question. In RDF there isn't a single
revision mechanism, because it's up to the developer/user to decide how
they want to model their data, it's not up to RDF people.

>
> Elias - key is balancing on the versioning
>
> Bruce - this discussion relates to clarifying the field
>
> 4) Meeting next week
>

To all, I hope we can continue the discussion based on this summary.

Cheers,

-Elias



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