Schema.org Alignment/Telecon 20120514

From DCMI_MediaWiki

Jump to: navigation, search
Schema.org Alignment Task Group telecon - 2012-05-14 11:00 EDT

This agenda:    http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120514
Chair:          Tom
Date:           Monday, 2012-05-14
Time:           11:00 AM Eastern Daylight Time
Dial-in:        +1-218-936-4141, participant Access Code 334034
IRC:            irc://irc.freenode.net/#dcmi
Mailing list:   http://www.jiscmail.ac.uk/lists/dc-architecture
Expected:       http://www.doodle.com/u3bh48x4f3p8db7r
                Tom, Antoine, Karen, Dan, Bernard, Kirsten, Corey

----------------------------------------------------------------------
Key links
   https://github.com/dcmi/schema.org                     - "Schema.org to Dublin Core mapping"
   https://github.com/dcmi/schema.org/issues              - issues raised re: mappings
   https://github.com/dcmi/schema.org/commits/master      - commit history for mappings
   http://wiki.dublincore.org/index.php/Schema.org_Alignment/Mappings_Details
   http://wiki.dublincore.org/index.php/Schema.org_Alignment/GithubIssueTracker

======================================================================
Source of mappings: Schema.org or Rdfs.org?

    Bernard raised this as Issue 9: schemaorg type-properties and rdfs:domain.
    On our telecon of 5 April, resolved to use rdfs.org as the basis of our
    mappings [2].  However, Dan Brickley (of Schema.org) and Michael
    Hausenblas (of Rdfs.org) _both_ think this is the wrong decision.  We
    should therefore reconsider on Monday's call.  Dan will be on the call to
    discuss his reasons.

    [1] https://github.com/dcmi/schema.org/issues/9
    [2] http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120405_Report

--  From the 2012-04-05 agenda:

    Do we base our discussions on formal semantics declared at schema.rdfs.org
    (RDFS classes and properties) which interprets the not-so-formal semantics of
    schema.org with the following rules
    
    type                   > rdfs:Class
    type hierarchy         > rdfs:subClassOf
    property               > rdfs:Property
    type has property      > rdfs:domain (the highest type in the type hierarchy having the property)
    property expected type > rdfs:range
    
    The owl schema at http://schema.org/docs/schemaorg.owl has the same interpretation.
    
    The prose at http://schema.org/docs/datamodel.html seems to be quite loose
       1. each property may have one or more types as its domains. The property may
          be used for instances of any of these types.
       2. each property may have one or more types as its ranges. The value(s)
          of the property should be instances of at least one of these types.
    
    The "may" and "should" are not as hard declarations as the formal rdfs:range
    and rdfs:domain ...

======================================================================
Issue tracking

    We decided to use the Github issue tracker [6] but its use has not gained
    any traction.

    Dan proposes that we do our work, at least in part, in the W3C Web Schemas
    Task Force [1,2].  Specifically, we could continue to use the dc-architecture
    mailing list, but track our issues on the Web Schemas issue tracker [3] (defining
    DC as a "product" with its own thread [4]) and occasionally report on progress to the 
    public-vocabs mailing list [5].

    [1] http://www.w3.org/wiki/WebSchemas
    [2] http://www.w3.org/2001/sw/interest/webschema.html
    [3] http://www.w3.org/2011/webschema/track/
    [4] http://www.w3.org/2011/webschema/track/products
    [5] http://lists.w3.org/Archives/Public/public-vocabs/
    [6] http://wiki.dublincore.org/index.php/Schema.org_Alignment/GithubIssueTracker

======================================================================
Documenting and publishing mappings

     Antoine has started work on an RDFa representation [1] of the 
     mappings in [2].  We will discuss this approach and address
     Kirsten's question [3,4] of how best we should incorporate new
     mappings into the set of mappings under consideration.

     Off-list, Dan has suggested that we approach mappings in the context of 
     usage patterns (application profiles).  He points out that with better 
     online documentation of both DCMI Metadata Terms and Schema.org, it should
     not be necessary to compile wiki pages such as [2] by hand and suggests that
     publication of mappings could therefore be simplified.

     [1] https://github.com/dcmi/schema.org/blob/master/mappings.html
     [2] http://wiki.dublincore.org/index.php/Schema.org_Alignment/Mappings_Details
     [3] https://github.com/dcmi/schema.org/issues/3
     [4] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1202&L=dc-architecture&F=&S=&P=14738
Personal tools