Re: First draft minimalist periodical/article proposal

On Mon, Dec 9, 2013 at 9:36 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
> On 12/8/13, 9:29 PM, Dan Scott wrote:
>
>>> From what I can tell reading the RDF Schema in
>>
>> http://schema.org/docs/schema_org_rdfa.html, I don't think schema.org
>> properties really need a home. I think you can just add a
>> "domainIncludes" assertion for a given property to add it to that
>> type, if it belongs there.
>
>
> The structure there is to help people find the properties they are looking
> for. After all, we asked to have citation moved to CreativeWork from
> somewhere buried down in the medical vocabulary, where it was hard to find.

I do remember that. If you check schema.org 0.99 via the handy
vocabulary history tool at http://lov.okfn.org, the "citation"
property only had a domainIncludes value of "MedicalScholarlyArticle".
And now it has a domainIncludes value of "CreativeWork", instead, so
it gets applied there and all of the types that are subclasses of
CreativeWork get to use it (including MedicalScholarlyArticle). That
said, I could be misunderstanding how RDFS works entirely... but I
don't think it was simply hard to find before; it would have been
invalid to use it on anything except MedicalScholarlyArticle. Well, as
invalid as anything in schema.org, where there's a bit of a history of
paving the footpaths (which makes sense).

> 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)..

> (There's also a similar issue [pardon the non-pun] with having "volume" 1)
> called "volume" [think geometry] and 2) in Periodical. One of the
> difficulties involving scanned books is that each volume often has its own
> metadata since it is a separate file. Book volumes, treated as extent in
> libraries, becomes individual items in those cases.)

Heh, good non-pun :) Yes, book volumes are good fun. Description of,
say, encyclopedia as a single bibliographic record makes a lot of
sense in one way but introduces a lot of friction when it comes to
attaching barcoded items to that record for the purpose of loaning &
placing holds. Evergreen has grown a couple of mechanisms for dealing
with that so that a user can identify and place a hold for a specific
print volume, but pain is involved (and really ends up being another
level of description).

>>>
>>> "Paging" as the class, perhaps?
>>>
>>> Paging (class)
>>>    pagination
>>>    startPage
>>>    endPage
>>>
>
> I came up with a slightly different version:
>
> Pagination (class)
>    pages
>    startPage
>    endPage
>
> pages can be anything from "356p." to the newspaper type "C1, c17-18" or the
> library "xxi, 257p." or "123"

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).

FWIW, I originally wanted to name the "pagination" property "pages" or
"pageNumbers", but balked because 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.

>> 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
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.

> 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

Received on Monday, 9 December 2013 17:46:11 UTC