JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  May 2012

DC-ARCHITECTURE May 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Schema.org Alignment Task Group telecon - 2012-05-14 - report

From:

Thomas Baker <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Mon, 28 May 2012 00:51:07 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (444 lines)

 Schema.org Alignment Task Group telecon - 2012-05-14 - report
 
 This report:    http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120514_Report
 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
 Mailing list:   http://www.jiscmail.ac.uk/lists/dc-architecture
 Github:         https://github.com/dcmi/schema.org
 Attended:       Tom, Antoine, Stuart, Karen, Dan, Bernard, Kirsten, Corey, Gregg Kellogg
 IRC:            Jon, Gordon
 
 ======================================================================
 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

 Tom: Question about how to represent the mappings. Affects whole workflow.
 Need to represent while working, then publish.

 Antoine: http://dcmi.github.com/schema.org/mappings.html

 Corey: FYI, the page Antoine references is also directly editable in github:
 https://github.com/dcmi/schema.org/blob/master/mappings.html. It uses github "pages"...

 Tom: mappings.html is hand-edited. Antoine saved wiki page as HTML and edited.
 Time-consuming, but not much more than creating human-readable documentation.

 Bernard: Starting from requirement for HTML version, there's not much added
 cost for hand-editing a page like this.

 Tom: Need for both human- & machine-readable versions.  RDFa approach provides
 single document for editing.  Re: requirements: one early requirement - have
 human and machine-readable versions. Some people in this call would be happy
 with Turtle, but others want HTML. For handling one requirement on
 human-readable version.  
 
 Antoin: Github issue tracking allows reference to part of a document.  Started
 to refer to changes by referring to line in mapping file (RDF version).
 http://dcmi.github.com/schema.org/mappings.html#schema:Organization_rdfs:subClassOf_dct:Agent
 This has problem that line numbers change when editing.  Ability to target one
 mapping without referring to line numbers in text. When we started to use
 github for issue tracking, uses line numbers. We started to refer to changes
 in mapping file. Problem: if you change the mapping files, line numbers
 change. RDFa allows to use HTML to refer to mappings.  Stable pointer to
 specific mapping.

 Jon: Just an FYI... The referenced line number in GitHub issues won't change
 if you reference a line number in a specific commit.

      Corey: +1 to referencing specific commits

 Jon: This looks like a good approach, but we still have the issue of
 referencing a specific mapping statement in issues and comments don't we?

 Antoine: We could have http://dcmi.github.com/schema.org/mappings.html#schema:Organization

       Jon: Ah. Ok
 
 Gregg: We have a way of generating RDFa from Turtle using
 templates/stylesheets.  The problem is that if you want to represent
 human-readable information other than mapping triples, you have to do it in
 static way, or represent it in RDF (so that the templates can generate the
 appropriate HTML).

    Antoine: Thanks a lot for the input, Gregg!
    Jon: Gkellog++

 Corey: Gregg, is the email you referred to something you sent offline? I'm not
 finding anything on any of my lists.

 Gregg: The perm link: http://lists.w3.org/Archives/Public/public-rdfa/2012May/0025.html

 Jon: The Open Metadata Registry has a vocabulary for status
    http://metadataregistry.org/concept/list/vocabulary_id/31.html

    Karen: +1, and maybe use the OMR vocab, or extend it
    Antoine: +1 (also for re-using the OMR voc!)
    Gordon: ++1 for adding definitions to the OMR vocab!
 
 Gregg: If I can be of any help with the mapping document, let me know.

 Jon: Is there a possibility to generate the HTML/RDFa from turtle using a script?

 Corey: Gregg's done the tweaking of the DCMI XSLT to generate HTML with
 Embedded RDFa output. # gkellogg++

 Gregg: Glad to help. Off now.

 ======================================================================
 Issue tracking
 
     We decided to use the Github issue tracker [6] but its use has not yet
     gained 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

 Dan: see http://www.w3.org/wiki/WebSchemas ... trackers mentioned.
 http://www.w3.org/2011/webschema/track/

 Corey: Danbri suggests that we engage the W3C Web Schema's task force efforts.

 Antoine: On issue tracking in Github: well, now we can use whatever anchor we
 want (and not only line numbers) we'd be in a better situation!  But of course
 I've got no objection to W3C issue tracker.

 [Discussion of porting issues over into w3c issue tracker.]

 Dan: The way the w3c group is framed, is a group within which 'schema.org as a
 project' listens and participates.

 Corey: Link to the feedback to schema.org set of issues:
 http://www.w3.org/2011/webschema/track/products/1

 Dan: We didn't make a working group to standardize Schema.org. Proprietary.
 Web Schemas is not a standardization body for Schema.org, but way to collect
 feedback. We use it for TODOs for FOAF. Would be happy if we could use for DC
 too.  Various semantic Web vocabularies - existence of schema.org has forced
 the issue of better communication between vocabularies.
 http://www.w3.org/wiki/WebSchemas

 Corey: I always thought the Issues tracker in W3C had W3C membership as a
 barrier. Need authentication, but as non-W3C affiliate, would this be a
 barrier?

 Dan: public w3c account should enable us to do this.  I believe you can get a
 public W3C account that will let you log in - see link. Public account for
 wiki, too. Believe the issue tracker understands people being "in the group"?
 http://www.w3.org/Help/Account/Request/Public

     Corey: danbri, thanks. just applied for a w3c public account.

 Jon: Part of the question is: Is the requirement for a W3C login a higher bar
 for participation than a GitHub login?  Is there enough additional value in
 the W3C issue tracker for the broader population of participants to change
 trackers and wikis at this point?

 Karen: As a non-programmer, github is more foreign to me than the w3c site.

 Dan: Hmm I've had same w3c account since 1997, let me make a new one and see
 how the tools work as a newcomer!

 First show of hands re: using W3C issue tracker and reporting to public-vocabs
 list.

    danbri:        +1
    kcoylenet:     +1
    bvatant:       +1
    chrpr:         +1 to using w3c issue tracker. -1 to moving discussion off dc-architecture.
    danbri:        dc-arch is fine for mail
    jonphipps:     -1
    antoine__:     +0. I'm ok with W3C issue tracker but I'm a bit reluctant to have only the issue tracking there...
    chrpr:         +1 to reporting to public_vocabs list. Call minutes, agendas, & major milestones.
         Antoine: corey++

 Jon: Like you said it's a matter of personal comfort

 Kirsten: Instructions for non-Members (http://www.w3.org/2004/08/invexp.html)
 for me seems to be more a barrier than joining github

    StuartSutton:          +1

 Dan: Jon, can you live w/ the w3c option?  I'm not promising w3c tools will be
 all happyness and joy, ... but it seems the right community to connect to.  So
 ... this is scoped to 'DC's mappings w.r.t. schema.org', right?  Not all of
 DC's arch work forever.

 Jon: GitHub's markdown syntax in the issues automatically hyperlinks
 GitHub-related references as well.

 Dan: I'm fine w/ it staying in DC's github; it's not a major issue.

 Jon: But that's a minor technical matter.

 Corey: To put my concern into the record: requiring github login for
 contributing to mappings _and_ w3c login for contributing to issue discussion
 provides double barrier to login.

 Karen: It's awkward, but if it works for most I'm not opposed.

 Antoine: @Dan: how easy would it be for us to use https://dvcs.w3.org/hg/webschema/summary ?

 Corey: Additionally, folks who land on the github mappings would then have to
 go to a separate site to see the corresponding discussions.

 Dan: No strong opinion either, all tools are annoying unless you use them daily
    Corey: +1 all_tools_are_annoying.  (at least I now know how to get more
    involved in W3C with a public account)

 Stuart: I have no strong opinion.

 RESOLVED: Continue using Github for issue tracking.

 ======================================================================
 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 ...
 
 Tom: Item1: Source of mappings: Schema.org or Rdfs.org?

 Karen: If we go for schema.org, do we have to re-invent the RDFS semantics in
 rdfs.org?  If we use Schema.org, won't we have to invent the type of thing
 that is in schema.rdfs.org. How can we hook things on this when so vague.

 Dan: Schema.org is vague, it has some mistakes.  Vague in many senses - put
 together quickly - mistakes... Hidden in the prose. In Schema, you don't
 notice problems in the other documentation.

 Dan: Classes give place in structure but you can't express everything
 machine-readably. We do use RDF Schema to describe Schema.org - comment,
 label, hierarchy, definition, etc. Differences around constraints - which
 properties go with which. Example: awards property - can attach to person or
 to a creative work. If you say domain is Person... In RDF Schema, people come
 up with "awardable thing" as superclass. Schema.org does not encourage this
 way of modeling. For the moment, these things are more like documentational
 hints than hard-and-fast. The documentation pages make a difference. Let's go
 back to focusing on the text.

 Dan: Latest schema.org RDFS:
 https://dvcs.w3.org/hg/webschema/raw-file/default/schema.org/drafts/alpha/rdfa.html

 Karen: Not sure it answers my question... To what extent will basing the DC
 mapping to Schema.org - is DC more similar to Schema.org or to Rdfs.org?
 Are there significant differences that would affect mappings?

 Jon: So we're not comparing http://schema.rdfs.org/all.rdf with
 http://schema.org/docs/schemaorg.owl ?

 Dan: Having gone through creation of schema.rdfs.org, highlighted a way we
 could make Schema.org closer to RDF. Discussions behind us. Work of Rdfs.org
 is more or less done now.  Was important in its time.

 Jon: I think at one time, the schema.org RDFS/OWL lagged behind the published
 schema.org. Is this no longer the case?  Since schema.rdfs.org says "We
 automatically scrape the Schema.org terms on a daily basis"

 Dan: OWL was updated as of last week. Need to write software. Right now not up-to-date.
 Intent is that the OWL should be up to date.  Right now, there is some lag.
 https://dvcs.w3.org/hg/webschema/raw-file/default/schema.org/drafts/alpha/rdfa.html

        <div typeof="rdf:Property" about="http://schema.org/awards">
        <span class="h" property="rdfs:label">awards</span>
        <span property="rdfs:comment">Awards won by this person or for this creative work.</span>
        <span>Domain: <a property="http://schema.org/domain" href="http://schema.org/CreativeWork">CreativeWork</a></span>
        <span>Domain: <a property="http://schema.org/domain" href="http://schema.org/Person">Person</a></span>
        <span>Range: <a property="http://schema.org/range" href="http://schema.org/Text">Text</a></span>
        </div>

 Bernard: I think it is misleading to talk about Domain and Range in this
 context. When Rdfs.org said it was scraping daily, interpreting Domain, but
 just uses these Union constructs. Still very uneasy.

 Tom: http://rdf.greggkellogg.net/distiller?format=turtle&in_fmt=rdfa&uri=https://dvcs.w3.org/hg/webschema/raw-file/default/schema.org/drafts/alpha/rdfa.html

 Karen: If what bernard says is the case, then it does sound problematic

 Dan: "Domain" is overloaded - need to resolve Schema.org "domain" to documentation.

 Antoin: At least it's schemaorg:domain, not rdfs:domain. So from that
 perspective the RDFa is more correct that schema.rdf.org!  Except that
 semantics of http://schema.org/domain is written nowhere.  That's the point.

 Dan: Our discussions get bogged down in infrastructure, methodology. Since
 Schema.org and DC are loosey-goosey, try to get working dataset of real world
 DC examples.

 Antoin: @Bernard: in fact your mail was a quite good definition for
 schemaorg:domain (informal) semantics.

 Dan: Semantics of schema:domain/range are in http://schema.org/docs/datamodel.html

 Karen: Maybe not either/or. I like Dan's idea of working with examples to see
 where they take us. Then we can go back and look at more structural/technical
 issues. But find it hard to talk about structural/technical issues without
 having examples.

     GordonD: +1 for working with examples AND assuming domain/range are compatible/same
     kcoylenet:          +1 use cases
    antoine:          +1

 Dan: Antoine, to push on examples a bit. One of the motvations for doing this
 work, so people don't have to agonize about whether to use Microdata or RDFa,
 etc.

 Karen: How do we move from examples to use cases?
 
 Dan: Sort of an interview-like model. Blog-like questionnaire: what are you
 [trying to do] with the metadata? What do your stakeholders think of lighter
 or heavier metadata?

 Antoine: Publish data in as many channels as possible.

 Dan:: would it be at all possible to get anchor links into the rdfa here:
 https://dvcs.w3.org/hg/webschema/raw-file/default/schema.org/drafts/alpha/rdfa.html,
 similar to what antoine__'s done here:
 view-source:http://dcmi.github.com/schema.org/mappings.html#schema:Organization_rdfs:subClassOf_dct:Agent

 Karen: I now understand better why Dan was asking for examples. The examples I
 gave were for stand-alone records. Maybe should be looking for examples of
 embedded DC?  Would be useful for commenting, and could also help people
 reference the documentation with more specificity outside of commenting
 process...

 Gordon: schema.org and dc may end up in same document if doc is assembled from different sources ...

 Dan: if there is a database of this somewhere - not sure where line is drawn.

 Karen: In my experience, DC used to described resources, not being used
 internally to resources - what I encounter is stand-alone records. Does that
 make a difference in terms of use cases?  May not be a viable use case for
 what we are talking about here.

 Dan: Antoine, do you have a better Mona Lisa than
 http://www.europeana.eu/portal/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F.html ?

 Antoine:
 http://www.europeana.eu/resolve/record/92037/25F9104787668C4B5148BE8E5AB8DBEF5BE5FE03
 was the link I was about to post, but it's clearly not Mona Lisa.

 Jon: This may be a na├»ve question but shouldn't we be mapping to the
 schema.org URIs regardless? For instance dct:BibliographicResource to
 http://schema.org/CreativeWork ?

 Dan: (yes please re mapping)

 GordonD: Merging/interoperating metadata standalone docs (records) is a
 different use-case from merging metadata embedded in texts

 Dan: view-source:http://www.europeana.eu/portal/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F.html

 Jon: Both schema.rdfs.org and schema.org reference the same URIs, but describe
 them slightly differently.

    Corey: jonphipps++ re: mapping URIs

        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:language" content="de-DE"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:rights" content="Deutsche Fotothek"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:source" content="SLUB/Deutsche Fotothek"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:subject" content="Malerei"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:subject" content="Bild"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:subject" content="Fotos"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:subject" content="Ortskatalog zur Kunst und Architektur"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:title" content="Mona Lisa - 2000"/>
        <meta about="http://www.europeana.eu/resolve/record/01004/AC2B3AA843934B18E804DD40BF6E7BDD9C04067F" 
            property="dc:type" content="image"/>

 Dan: How many of those properties could usefully have schema:keywords
 schema:name etc added too? (then this group is the group working out such
 details)

 Jon: It seems to me that the http://schema.org URIs MUST be what we use for canonical definitions

 Antoine: @danbri: http://www.europeana.eu/resolve/record/03919/FCD38BDE7A03579F24BEDA5D157943B75BB36F11 is the one

 Dan: The One.  http://www.europeana.eu/portal/record/08502/91B9F52D5EE11B19F0C09C7B5FEA194B31B7049D.html is another.

 Tom: suggest raising this in DCAM meeting tomorrow/tuesday

 Jon: schema.rdfs.org has no ability to 'define' URIs that don't exist in a
 domain that it controls, only to provide an alternative description

        GordonD:  +1 for continuing/merging some aspects of this discussion with the DCAM call tomorrow
        Corey: +1 re: tomorrow, and I have to run soon. Also, I may have to cut off the DCAM call a little bit early tomorrow.
        Antoine: +1 but I'm not sure I understand there is common ground!
        GordonD:  Would be good to confirm that there is no common ground!

 Karen: Difference btw saying I'm describing something over there as to
 describing something within the resource. Library md is about describing
 something out there. But if you are inside the thing, provide information for
 people using

 Dan: rediscovers 2001 DC8 slides, http://dublincore.org/workshops/dc8/DCMIArchitecture2/sld001.html
 Re examples.

 Jon: This may apply: http://www.jenitennison.com/blog/node/170


-- 
Tom Baker <[log in to unmask]>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager