Schema.org Alignment Task Group telecon - 2012-05-14 - report
This report: http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120514_Report
Date: Monday, 2012-05-14
Time: 11:00 AM Eastern Daylight Time
Mailing list: http://www.jiscmail.ac.uk/lists/dc-architecture
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  of the
mappings in . 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  by hand and suggests that
publication of mappings could therefore be simplified.
Tom: Question about how to represent the mappings. Affects whole workflow.
Need to represent while working, then publish.
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
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).
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
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
Antoine: Thanks a lot for the input, Gregg!
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
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.
We decided to use the Github issue tracker  but its use has not yet
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  (defining
DC as a "product" with its own thread ) and occasionally report on progress to the
public-vocabs mailing list .
Dan: see http://www.w3.org/wiki/WebSchemas ... trackers mentioned.
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:
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.
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
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"?
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
chrpr: +1 to using w3c issue tracker. -1 to moving discussion off dc-architecture.
danbri: dc-arch is fine for mail
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.
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
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 . 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.
-- 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:
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
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.
<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>
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.
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
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
GordonD: +1 for working with examples AND assuming domain/range are compatible/same
kcoylenet: +1 use cases
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,
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:
similar to what antoine__'s done here:
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
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
what we are talking about here.
Dan: Antoine, do you have a better Mona Lisa than
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
Dan: (yes please re mapping)
GordonD: Merging/interoperating metadata standalone docs (records) is a
different use-case from merging metadata embedded in texts
Jon: Both schema.rdfs.org and schema.org reference the same URIs, but describe
them slightly differently.
Corey: jonphipps++ re: mapping URIs
property="dc:rights" content="Deutsche Fotothek"/>
property="dc:source" content="SLUB/Deutsche Fotothek"/>
property="dc:subject" content="Ortskatalog zur Kunst und Architektur"/>
property="dc:title" content="Mona Lisa - 2000"/>
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
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
Dan: rediscovers 2001 DC8 slides, http://dublincore.org/workshops/dc8/DCMIArchitecture2/sld001.html
Jon: This may apply: http://www.jenitennison.com/blog/node/170
Tom Baker <[log in to unmask]>