- From: Shlomo Sanders <Shlomo.Sanders@exlibrisgroup.com>
- Date: Wed, 11 Dec 2013 05:18:54 +0000
- To: Karen Coyle <kcoyle@kcoyle.net>
- CC: Ross Singer <ross.singer@talis.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <AF2825C7-2381-4FE4-A264-7ED07FA59045@exlibrisgroup.com>
+1
Thanks,
Shlomo
Sent from my iPad
On Dec 10, 2013, at 18:28, "Karen Coyle" <kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>> wrote:
On 12/10/13, 3:28 AM, Ross Singer wrote:
By "elsewhere" I mean PeriodicalIssue.
In your Series example, the range of episode/episodes is
http://schema.org/Episode
In your proposal, aren't these strings?
Yes, but as you know, ranges in schema are suggested, not required. Really, I think a lot of hairs are being split here, given the actual goals.
kc
-Ross.
On Dec 10, 2013 12:37 AM, "Karen Coyle" <kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net>> wrote:
On 12/9/13, 6:33 PM, Ross Singer wrote:
Karen, can you extrapolate why you think it would be a journal
property?
It seems to me that journal hasMany volumes/issues, which would put
these properties elsewhere.
Hmmm. I'm not sure what you mean by "elsewhere." The periodical is
something that is published over time in discrete parts, and the
serially published parts are usually in the form of volumes (that
are usually temporal, e.g. they represent a year of publication) and
issues (that are the serial "manifestations", numbered subordinate
to the volume, and with a physical presence). It is a kind of
whole/part relationship. However, it is a whole/part relationship
that has a great deal of variation, so no one pattern will work for
periodicals in general. In other words, we've got to fudge it somewhere.
However, I think that your point is that the metadata has to have
the same structure as the periodical. I'm saying that doing so 1) is
not necessary for the schema.org<http://schema.org> <http://schema.org> markup use case
and 2) will not be possible without great complication and 3)
schema.org<http://schema.org> <http://schema.org>, with its flat namespace, in any case
will not reproduce the periodical structure without making the
periodical schema very complicated.
I think we can do periodical in a way that is analogous to
http://schema.org/Series, which has the properties "season" and
"episode" where episode is one instance within a season within a series.
kc
-Ross.
>
> kc
>
>
>>
>> -Ross.
>>
>>
>> kc
>>
>>
>>
>> -Ross.
>>
>>
>> On Mon, Dec 9, 2013 at 1:40 PM, Karen Coyle
<kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
>> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net>>>
>> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net>>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>> wrote:
>>
>>
>>
>> On 12/9/13, 9:45 AM, Dan Scott wrote:
>>
>>
>> Properties that obviously cross
different classes,
>> IMO, need
>> a general home.
>> Someone marking up book chapters may
not think to
>> look in
>> Periodical or
>> Article for pagination patterns. (I've
talked with
>> DanBri
>> about this, but
>> schema desperately needs a good
visualization
that is
>> graph-oriented, not
>> hierarchical.)
>>
>>
>> I think the mechanism is to simply add a
domainIncludes
>> declaration
>> for each property of interest pointing at
the type (for
>> example,
>> BookChapter, if it gets defined)..
>>
>>
>> Which one could have done with MedicalArticle
in order to
>> make use
>> of citation. So either one takes the view that
you only
need
>> domainIncludes, or that the structure matters, not
>> sometimes one
>> way, some times the other.
>>
>> Honestly, I think that schema.org<http://schema.org>
<http://schema.org> <http://schema.org>
<http://schema.org>
>> <http://schema.org> itself hasn't
>>
>> made this decision -- which is why we end up
looking at it
>> in both
>> ways. Since "the mechanism is simply to add a
domainIncludes
>> declaration..." as a technical solution, I
like to look at
>> what will
>> help people using schema.org<http://schema.org>
<http://schema.org> <http://schema.org>
<http://schema.org>
>> <http://schema.org> as a strong
>>
>> motivator for decisions. It's still a crap
shoot, I admit.
>>
>>
>>
>> I'll admit to being surprised at the idea
of adding a
>> Pagination
>> class; that seems like a much less useful
thing to
>> potentially
>> link to
>> than an individual issue. And there is no
complexity in
>> the pages /
>> startPage / endPage properties that binds
their
>> relationship
>> (vs. say
>> a Contributor class that would let one
encode or
>> encapsulate the
>> nature of the contribution, rather than
requiring every
>> possible
>> type
>> of contributor to become its own property).
>>
>>
>> I don't know what you mean by "every possible
type of
>> contributor to
>> become its own property" but the reason that I
have for
moving
>> pagination out of periodical is that it is
also useful for
>> book/book
>> chapter, unless you expect people to
domainIncludes Book to
>> Periodical. That, I think, would not occur to
many people.
>>
>>
>>
>> FWIW, I originally wanted to name the
"pagination"
property
>> "pages" or
>> "pageNumbers", but balked because
schema.org<http://schema.org> <http://schema.org>
<http://schema.org>
>> <http://schema.org> <http://schema.org>
>>
>>
>> has deprecated most of
>> the plural attribute names in favour of
the singular.
>> That said,
>> in my
>> research last week checking the MLA and
APA style
>> manuals, "page
>> numbers" was the most commonly used term
between
the two,
>> followed by
>> "pagination". So I would suggest either
"pageNumbers" or
>> "pagination".
>> This would avoid any possible terminology
conflict with
>> "page(s)" as
>> in the assistants to members of
parliament, or (heh)
>> people-typically-teenagers who shelve books at
libraries.
>>
>>
>> Both pageNumbers and pagination sound fine.
>>
>>
>>
>>
>> But given that you want Periodical
to be a
>> subclass of
>> Series,
>> shouldn't that line reflect that
deeper
nesting and
>> actually look like
>> the following?
>>
>> Thing > CreativeWork > Series >
Periodical >
>> Article
>>
>>
>>
>> I have no idea what Series means in
relation to
>> Periodical,
>> and hadn't
>> included it in my proposal.
>>
>>
>>
http://www.w3.org/community/______schemabibex/wiki/Periodical_______Article_minimal
<http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal>
>>
<http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal
<http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>>
>>
>>
>>
>>
<http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal
<http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>
>>
<http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal
<http://www.w3.org/community/schemabibex/wiki/Periodical_Article_minimal>>>
>> is the right page for me to be looking at,
right? If
>> so, there's a
>> section at the top that says:
>>
>> """
>> Subclass Periodical to Series
>>
>> Thing > CreativeWork > Series
>>
>> Periodical will also need to be
sub-classed to Series
>> to make
>> use of...
>> """
>>
>> This is why I thought you want Periodical
to be a
>> sublass of Series.
>>
>>
>> Ah, yes. I'd forgotten that the start and end
dates were in
>> Series.
>> I also suggest further down in the Intangible
area that
perhaps
>> those should be moved to Intangible since that
was one
of those
>> opportunistic subclassings that I find so
illogical. So it
>> again
>> brings up the question of whether there is any
logic to
>> schema.org<http://schema.org> <http://schema.org> <http://schema.org>
<http://schema.org>
>> <http://schema.org> or if one simply wants to
subclass
>> promiscuously
>>
>> to get whatever properties one needs. I can go
with
either some
>> semblance of logical arrangement or treating
schema.org<http://schema.org> <http://schema.org>
<http://schema.org>
>> <http://schema.org>
>> <http://schema.org> as a flat vocabulary (and
doing a
lot of
>>
>> opportunistic subclassing) but being on the
pendulum
>> between them
>> gives me whiplash. I think this is a problem
that many are
>> having
>> with schema, and unfortunately I don't see it
getting
>> cleared up any
>> time soon. We should probably just decide what
our goals
>> are and not
>> worry too much about the whole. (I think this
is what the
>> medical
>> folks did.)
>>
>> kc
>>
>>
>>
>> I see them as bibliographically
distinct, for
>> reasons that I articulated to Antoine
a while back.
>> Although
>> series and
>> periodical share the use of volume
numbers, I
wouldn't
>> consider a periodical
>> a type of series, for my bibliographic
concept of
>> series.
>>
>>
>> Okay.
>>
>> If, as you say
>> above, the structure in schema isn't
significant,
>> then this
>> deeper nesting,
>> IMO, isn't necessary, and yet sends
the message
>> that the
>> structure IS
>> significant. This, again, is a
contradiction within
>> schema
>> that encourages
>> structure yet ignores it.
>>
>>
>> I don't think I said, and did not mean to
imply in any
>> way, that the
>> structure in schema is not significant. I
was just
>> trying to
>> point out
>> the domainIncludes approach to go along
with the
>> subclass option.
>>
>> Thanks,
>> Dan
>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>
>> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net
<mailto:kcoyle@kcoyle.net>>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>
>> http://kcoyle.net
>> m: 1-510-435-8234 <tel:1-510-435-8234>
<tel:1-510-435-8234 <tel:1-510-435-8234>> <tel:1-510-435-8234
<tel:1-510-435-8234>
>>
>> <tel:1-510-435-8234 <tel:1-510-435-8234>>>
>> skype: kcoylenet
>>
>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>
http://kcoyle.net
>> m: 1-510-435-8234 <tel:1-510-435-8234>
<tel:1-510-435-8234 <tel:1-510-435-8234>>
>> skype: kcoylenet
>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net>
<mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
http://kcoyle.net
> m: 1-510-435-8234 <tel:1-510-435-8234>
> skype: kcoylenet
--
Karen Coyle
kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net> http://kcoyle.net
m: 1-510-435-8234 <tel:1-510-435-8234>
skype: kcoylenet
--
Karen Coyle
kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
Received on Wednesday, 11 December 2013 05:19:25 UTC