[Trac] [OpenMath] #39: Allow for arbitrary metadata referenced by URI

[OpenMath]

#39: Allow for arbitrary metadata referenced by URI
------------------------------+---------------------------------------------
     Reporter:  clange        |          Owner:  kohlhase  
         Type:  proposal      |         Status:  new       
     Priority:  major         |      Milestone:            
    Component:  OM3 Standard  |        Version:            
   Resolution:                |       Keywords:            
Include_gantt:  0             |   Dependencies:            
   Due_assign:  YYYY/MM/DD    |      Due_close:  YYYY/MM/DD
------------------------------+---------------------------------------------
Comment (by kohlhase):

 Replying to [comment:5 clange]:

 I am very much in favor of such a redesign of the CD Metadata. In fact I
 had been thinking about doing something very similar for the OMDoc format
 (I had not read your discussion unfortunately). I agree that the signal-
 no-error-but-preserve policy for applications that do not understand a
 Metadata URI is probably the best one here.

 The questions of updating the metadata on an edit is a secondary one,
 since we are discussing about the data format here and they belong into
 the application realm.

 > Replying to [comment:4 jhd]:
 > > Firstly, note that I AM in favour of some such more in the area of
 greater use of metadata.
 > Sure, I think I didn't get you wrong in that; sorry when it sounded like
 this.
 > > However, most applications of the sort I know (CA systems etc. - SWiM-
 like applications are clearly different) tend to ignore metadata, and
 should be left free to ignore it WITHOUT KNOWING what it is that they are
 ignoring.
 > That sounds reasonable. However, from what you say I assume that CAS-
 like systems have also ignored the ''CDDate''-like metadata of OpenMath 2,
 so it wouldn't make any difference to them, or am I getting sth. wrong?
 > >     * the minimum metadata vocabulary that a CD-aware application must
 support is the one from OpenMath 2.
 > > Fine, though there's no reason why we shouldn't DCize it in the
 process
 > From my point of view, I'd of course support dropping the old syntax,
 but maybe we want to remain backwards-compatible.
 > >     * optionally, an application can also support a syntax like
 dc:author. Now we could say that if this syntax is supported the full DC
 vocabulary must be supported,
 > > 'supported' in the sens eof not causing an error, I assume.
 > Yes -- supporting in the sense of doing sth. meaningful with it should
 really be up to every individual application. But "not causing an error"
 is probably not enough. For applications that can load and store OpenMath,
 I'd rather require "not causing an error ''and preserving the data''".
 > >     * optionally, an application can support the syntax sketched in
 the ticket that allows for arbitrary metadata. In that case, at least the
 URIs pointing to the DC metadata vocabulary must be supported; further
 metadata vocabularies can be supported.
 > > Possibly - I don't know enough to comment.
 > That wouldn't be too hard. In terms of the RELAX NG schema it would even
 be very easy to define, e.g. an element ''meta'' with an attribute
 ''property'' or type ''URIref''.  And then in the spec we'd give a list of
 URIs (i.e. vocabularies) that must be supported as values of that
 attribute. Supporting any other vocabularies would be up to every
 individual application, but the great advantage of that would be, if we
 combine it with above requirement of preserving unknown metadata upon
 load/store/import/export/send/…, applications that ''do'' understand
 additional metadata would be able to exchange them among themselves,
 without other intermediate applications disturbing the communication.

-- 
Ticket URL: <https://trac.kwarc.info/OM3/ticket/39#comment:8>
OpenMath <http://www.openmath.org>
The development of the OpenMath Standard and Content Dictionaries.