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