Allow for arbitrary metadata referenced by URI

[jbs1]

migrated from Trac, where originally posted by clange on 13-Jun-2008 5:23pm

An even more (r)evolutionary approach than #38 would be inspired by RDFa, a specification that allows for embedding arbitrary metadata into HTML. There could be one generic metadata element that would just point to the URI of the respective metadata field in the vocabulary where it is defined, e.g.

<meta property="http://purl.org/dc/elements/1.1/author">Name</meta>

That would be slightly harder to write (but could be facilitated by XML entities, and it's meant for machine processing anyway) and validate (if we talk about simple-minded approaches like DTD validation), but it would be much more extensible, as authors could easily refer to new metadata vocabularies.

If this is too revolutionary, let me propose to keep it optional. For commonly-used metadata vocabularies, one could have a syntax like <dc:author> as syntactic sugar for the general metadata element, and in cases where there was an idiosyncratic OpenMath element like CDDate, one could even keep that (but maybe deprecate it).

[jbs1]

migrated from Trac, where originally posted by jhd on 13-Jun-2008 11:14pm

This sounds "obvious", but I have a slight worry. It means that any tool that processes such data (many don't, e.g. CA systems), would need to be able to handle this genericity (which I strongly suspect is non-algorithmic), rather than a fixed language, such as DC.

[jbs1]

migrated from Trac, where originally posted by clange on 23-Jun-2008 6:33pm

James, you're right, there is no generally applicable way for handling all kinds of metadata. The application must have a certain understanding of what some metadata field means.

I'd suggest to treat this similarly to CDs: some mathematical applications don't support all possible OpenMath CDs either, but just some default set. So we could easily specify that applications need not support any metadata beyond the default ones (but should probably preserve ones they don't understand). Or we could even introduce a metadata negotiation process as done for CDs in chapter 5.3 of the OpenMath 2.0 spec. How about the following?

• the minimum metadata vocabulary that a CD-aware application must support is the one from OpenMath 2.
• 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, and we could add a few other reasonable ones, such as Creative Commons for licencing (as done in OMDoc, see chapter 1.2 of http://www.omdoc.org/pubs/omdoc1.2.pdf)
• 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.

[jbs1]

migrated from Trac, where originally posted by jhd on 23-Jun-2008 10:26pm

Firstly, note that I AM in favour of some such more in the area of greater use of metadata. 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.
* 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
* 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.
and we could add a few other reasonable ones, such as Creative Commons for licencing (as done in OMDoc, see chapter 1.2 of http://www.omdoc.org/pubs/omdoc1.2.pdf)
* 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.

[jbs1]

migrated from Trac, where originally posted by clange on 23-Jun-2008 11:41pm

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.

[jbs1]

migrated from Trac, where originally posted by jhd on 24-Jun-2008 8:17am

Replying to [comment:5 clange]:

Replying to [comment:4 jhd]:

* 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.
This is a more general question, but a good one. Personally, I think moving the metadata that is inthe scope of DC to DC syntax would be a GOOD THING.
'supported' in the sense of 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".
That SOUNDS reasonable, but what worries me is a field like LastEditedDate: an application that preserved this in ignorance of its meaning would possibly not be doing the right thing.

[jbs1]

migrated from Trac, where originally posted by clange on 24-Jun-2008 12:03pm

Replying to [comment:6 jhd]:

Replying to [comment:5 clange]:

Replying to [comment:4 jhd]:

'supported' in the sense of 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".
That SOUNDS reasonable, but what worries me is a field like LastEditedDate: an application that preserved this in ignorance of its meaning would possibly not be doing the right thing.
Hmm, my view on this is that deleting such a field that an application does not understand would do most harm. Not updating it is the lesser of two evils IMHO. I think it's as excusable as, e.g., not adding the currently logged-in user to dc:contributors – i.e. a feature that would be nice to have but is not completely essential.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 1-Jul-2008 5:15am

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.

[jbs1]

migrated from Trac, where originally posted by jhd on 1-Jul-2008 7:05am

Replying to [comment:8 kohlhase]:

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.
I am trying to get in touch with the local DC expert, to see what practice is there, since it seems to me that MUCH (status is the obvious exception) of our metadata are DC-like.
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.
secondary, possibly, but I think still important.

[jbs1]

migrated from Trac, where originally posted by clange on 8-Sep-2008 4:18pm

One addition for the new Title element: I propose mapping Title to dc:title.

[jbs1]

migrated from Trac, where originally posted by clange on 16-May-2014 12:48am

I'm sure this has no chances, as it would be a major evolution of the metadata aspect of the CD language, so feel free to close it.