Re: proposal just for article

On Tue, Dec 10, 2013 at 11:13 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> Sounds good Niklas. Do you want to add "justARticle2" to the wiki?
>

Well, I started out with your new example. But after renaming DocumentIssue
to PeriodicalIssue, adding a link (property="isPartOf"), putting
volumeNumber to the issue, and connecting the things with identifiers, it
ended up exactly like [1], but with PeriodicalIssue instead of Periodical,
and pages instead of pagination. :)

(From what I've gathered, an issue is basically identified within a
publication by a combination of volume and issue number?)

So I'd rather see if we can continue on Dan's original proposal by merging
your versions with that. (It's after midnight now and I have loads of work
tomorrow, so I'm afraid this mail is all from me prior to the telecon.)

I do get somewhat nervous about the partOf because we don't always know for
> sure what is part of what. But maybe if you include some examples in your
> proposal we can see how that goes.
>

I just seek to replace partOfPeriodicalIssue and partOfPeriodical in the
original proposal with isPartOf. Same example otherwise. (I'm sure it is
transitive, so that if an article is part of an issue which is part of a
periodical, that article is also part of that periodical. In a general
case, stating just that directly would thus be perfectly ok.)

The reason I included types for issues and volumes is that there were
> comments that the volume and issue numbers need a home -- a class. If
> Periodical can't be that class, then what is? Dan used Issuance as a class,
> I believe to get around that. So it seems that the volume number needs to
> be a property of the volume, and the issue number needs to be a property of
> the issue. If you can find another place for them, that's great. I would
> like for volume number to be available both to books and periodicals.
>

Yes, that'd be good. I think:

    schema:volumeNumber schema:domainIncludes schema:Book,
schema:PeriodicalIssue .

is enough for now (plus some examples of books with volume numbers). Once
the set of classes becomes unwieldy (at, say, 4-7 classes?), or the same
set appears for many properties, it is time to introduce a common
superclass for them (reasonably using, as Dan suggested, Document like in
BIBO).

That is, unless many kinds of creative works can do with a volume
number/string (like films, albums, etc.)?

And it is close to the original -- although the original had issuance. But
> the fact of being reduced, to me, is the key point -- and if it can be both
> reduced AND compatible with the full proposal, then I'll be very happy.
>

Sounds great.

Cheers,
Niklas

[1]:
http://www.w3.org/community/schemabibex/wiki/Periodical_Article_minimal#Article.2C_RDFa.2C_from_Niklas



> kc
>
>
> On 12/10/13, 1:58 PM, Niklas Lindström wrote:
>
>> There are seven distinct items here [1] – shouldn't they be linked
>> together (using e.g. partOf)? Also, some items can be identified as the
>> same (using the pattern I showed earlier, in both RDFa and microdata).
>>
>> Since this proposal defines types for both issues and volumes, doesn't
>> it end up being very close to the original proposal? Albeit with a
>> reduced set of properties.
>>
>> (And I'd like to reduce the set of properties where possible. I prefer
>> to use partOf/hasPart instead of distinct properties for each possible
>> range, unless required by use cases. Externally linked parts/containers
>> can be typed too, to mitigate the risk of consumers not getting the
>> nature of the composition.)
>>
>> Cheers,
>> Niklas
>>
>> [1]:
>> http://www.google.com/webmasters/tools/richsnippets?q=uploaded:
>> 8004ed34f803aa5bb45ed9a29856636c
>>
>>
>>
>> On Tue, Dec 10, 2013 at 10:25 PM, Thad Guidry <thadguidry@gmail.com
>> <mailto:thadguidry@gmail.com>> wrote:
>>
>>     Big Awesome
>>     +1
>>
>>     Thanks for this Karen !
>>
>>     And Schema.org has needed an generic Intangible class for Pagination
>>     for some time now that is not sequestered in CollectionPage or
>>     WebPage types for that matter.
>>
>>     FYI, the flowers-roots (bottom-up) approach is really the best for
>>     Schema.org development and proposals.
>>     Classes and Types (roots) can develop easily from the needed
>>     properties that are collected and gathered (flowers).
>>
>>     Hope you like that analogy, and hang in there, there will probably
>>     be many more bumpy rides as you guys go along, I'm sure. :-)
>>
>>
>>
>>     On Tue, Dec 10, 2013 at 2:06 PM, Karen Coyle <kcoyle@kcoyle.net
>>     <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>         I have done a new (and probably my last) proposal that only
>>         covers article markup, leaving aside the description of
>>         periodicals qua periodicals and any information about volumes
>>         and issues except for the numbering needed to locate the article.
>>
>>         http://www.w3.org/community/__schemabibex/wiki/Article
>>
>>         <http://www.w3.org/community/schemabibex/wiki/Article>
>>
>>         You can add any alternatives you prefer to this proposal, or
>>         make other proposals if you see this differently.
>>
>>         kc
>>         --
>>         Karen Coyle
>>         kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>         m: 1-510-435-8234 <tel:1-510-435-8234>
>>         skype: kcoylenet
>>
>>
>>
>>
>>     --
>>     -Thad
>>     +ThadGuidry <https://www.google.com/+ThadGuidry>
>>     Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
>>
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>