Skip to content

Incorporate Dublin Core and Creative Commons instead of idiosyncratic metadata #38

New issue
New issue
Closed
Closed
Incorporate Dublin Core and Creative Commons instead of idiosyncratic metadata#38
Assignees
jbs1

Description

@jbs1
jbs1
opened on Jul 6, 2016

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

This is a rephrased version of proposal #12. I think many of these problems can be solved by getting rid of some (not all) of the idiosyncratic OpenMath CD metadata elements and replacing them by Dublin Core, Creative Commons, and other well-known metadata ontologies. One could either do this by statically importing certain XML schemas into the OpenMath XML schema, as e.g. OMDoc 1.2 does, too. That would give us elements like

<dc:author>Name</dc:author>

Several existing elements of the CD language could be abolished or deprecated in favour of this:

  • CDGroupName maps to dc:identifier
  • CDGroupDescription maps to dc:description
  • CDName maps to dc:identifier (see comment below for a discussion)
  • Description maps, quite naturally, to dc:description
  • CDDate maps, naturally, to dc:date
  • For CDComment, there is nothing in Dublin Core, but rdfs:comment from the widely used RDF Vocabulary Description Language (RDFS) could be used.
  • CDDefinition/Name maps to dc:identifier (see comment)
  • CDSignatures/Name maps to dc:identifier
    See http://dublincore.org/documents/dces/ for the specification of the Dublin Core Metadata Element Set (DCMES). (DCMI Terms is actually a more modern and fully backwards-compatible variant, which should probably be preferred. Still, DCMES is more widely used.)

And see #39 for a more revolutionary proposal than this one.

Activity

  1. jbs1
    self-assigned this
    on Jul 6, 2016

  2. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

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

    To shortly recapitulate the discussion about CDName or Name vs. dc:identifier (2008/02/26 on the OM3 list):

    • I (Christoph) proposed this.
    • James had general concerns
    • I said that according to the Dublin Core spec, such an identifier is meant to be "unambiguous within a given context"
    • Paul said that actually CDBase + CDName is the identifier
    • Michael agreed with Paul

    … and then I didn't reply anymore and forgot the issue. I'm sorry for that.

    So let me now reply: I'm still in favour of dc:identifier, because

    1. the CDBase has to be given anyway. (CDBase is, BTW, a metadata field for which there is no obvious Dublin Core or other replacement.)
    2. dc:identifier is not meant to be the same as a URI. In fact, a URI for some OpenMath CD element with a name would be constructed as CDBase + CDName, same as the URI of a symbol is constructed as CDBase + CDName + Name. Still, in the local scope of a CD, the unambiguous identifier of a symbol is just its Name.

  3. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

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

    Also note #71 for notes about turning CDComment into a "real" metadata field

  4. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

    migrated from Trac, where originally posted by david on 9-Sep-2008 2:30pm

    I'm against replacing the OM* elements with dc ones.

    Any software that would want to extract RDF metadata out of the CDs would need some tuning to know whereto find the metadata even if were encoded in dc format. For such software building a mapping from OM* to dc:* into the extraction process isn't really a big deal.

    For any other use, including the main use of specifying to implementors of the mathematical functions, the mathematical properties to be implemented, using elements from multiple vocabularies complicates things for no gain. If there is a distinct set of OM* elements then CD tools can easily know what elements need to be implemented, if we include subsets of external vocabularies (dc, rdfs, owl?, ....)
    then this is harder to document and harder to enforce.

  5. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

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

    Replying to [comment:6 david]:

    Any software that would want to extract RDF metadata out of the CDs would need some tuning to know whereto find the metadata even if were encoded in dc format.
    Right, but maybe a bit less than before, if we allow for metadata in any reasonable place of a CD (#40)
    For such software building a mapping from OM* to dc:* into the extraction process isn't really a big deal.
    That's right; that's what I'm currently doing (my implementation)
    If there is a distinct set of OM* elements then CD tools can easily know what elements need to be implemented,
    Here my concern is that there are some proposals for reinventing the wheel on our part, i.e. inventing new metadata-like elements for [ticket:12 authors] and [ticket:18 licensing], and maybe more. For such metadata (and for many of those we already have in OpenMath) there are existing and well-maintained vocabularies.
    if we include subsets of external vocabularies (dc, rdfs, owl?, ....)
    then this is harder to document and harder to enforce.
    If we leave it to the applications how many metadata vocabularies they want to support, can't we specify a negotiation algorithm for that, as we do for CDs? (Or how about actually defining some mapping that allows for handling external metadata vocabularies exactly like OpenMath CDs? -- and getting this negotiation for free.)

  6. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

    migrated from Trac, where originally posted by clange on 9-Sep-2008 6:17pm

    Replying to [comment:6 david]:

    I'm against replacing the OM* elements with dc ones.
    One more comment about this: If we follow your decision, I would at least suggest that we specify a canonical mapping of those CD elements for which it is possible to DC, e.g. in an appendix of the spec. I'm not used to writing specs and appendices thereof, so I don't know whether that's a good thing, but from a developer's point of view it is certainly good if you don't have to figure out a reasonable CD -> DC mapping yourself, if we have already done so.

  7. jbs1 commented on Jul 6, 2016

    @jbs1
    jbs1
    on Jul 6, 2016
    Author

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

    I suspect that the "next version" of OpenMath will be a relatively minor increment, so even this will be too revolutionary. Except that comment [comment:8] about codifying the mapping of our idiosyncratic vocabulary to Dublin Core is still valid.

  8. kohlhase commented on Oct 2, 2017

    @kohlhase
    kohlhase
    on Oct 2, 2017
    Member

    moved to OpenMath/OMSTD#37

  9. kohlhase
    closed this as completedon Oct 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions