Re: proposal just for article

On 12/10/13, 3:47 PM, Niklas Lindström wrote:
>
> On Tue, Dec 10, 2013 at 11:13 PM, Karen Coyle <kcoyle@kcoyle.net
> <mailto: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. :)

Well, perhaps that means it's on the right track. Getting to the same 
place from different starting points may be a good thing.


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

If one can be a subset of the other, then perhaps we can, in 
documentation, provide "views" that serve different use cases, but where 
there is a whole where those use cases all fit together. That sounds 
almost too good to be true... but if it works, that's great.


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

So this then would be tied to the collection proposal, which would bring 
isPartOf out of its current place sub to a collection of web pages.



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

Music CDs and audio book CDs can come with volumes, although theirs are 
volumes like the book volumes -- a fixed set, rather than an opened 
ended one like periodicals. I have DVDs for TV series that have volume 
numbers. It seems that it would be hard to exclude the possibility of of 
other uses.

I'm also currently drawing a blank on whether there are other things in 
the world aside from creative works that have the concept of volume 
attached to them. It's a negative that I cannot prove.

kc

>
>     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:__8004ed34f803aa5bb45ed9a2985663__6c
>         <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>
>         <mailto: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>
>              <mailto: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>
>
>                  <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>
>         <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
>
>
>
>
>              --
>              -Thad
>              +ThadGuidry <https://www.google.com/+__ThadGuidry
>         <https://www.google.com/+ThadGuidry>>
>              Thad on LinkedIn <http://www.linkedin.com/in/__thadguidry/
>         <http://www.linkedin.com/in/thadguidry/>>
>
>
>
>     --
>     Karen Coyle
>     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 http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 11 December 2013 01:21:14 UTC