Re: Article Proposal

On 12/13/13, 1:09 AM, Adrian Pohl wrote:

> - "A publication in any medium issued in successive parts bearing
> numerical or chronological designations and intended, such as a
> magazine, scholarly journal, or newspaper" <- Is this actually a full
> sentence?

:-) No, something got lost. The original statement went on "... 
intended... to continue indefinitely." It was cribbed from the 
definition in AACR2.

>
> Relation between schema:Periodical and schema:Blog:
> Currently, schema:Blog is located in the schema.org hierarchy as
> follows:  Thing > CreativeWork > Blog. I guess the proposal should
> include moving schema:Blog to Thing > CreativeWork > Periodical > Blog.
> This would also make sense regarding the property schema:issn that
> belongs to schema:Periodical as some blogs actually have an ISSN. (I
> just heard about the German blog wisspub.net receiving an ISSN.[1])


I understand your statement about blogs, and to me it is factually 
correct, but I'm not sure the library "continuing resource" point of 
view would be well received. Perhaps we could suggest it as part of our 
proposal and see what the reaction is.

kc

>
> Examples:
> - I would like to see another example for non-traditional periodicals
> like a webcomic or a blog. I could provide that one myself if you want
> to.
>
> As I haven't been taking part in the discussion for the last weeks and
> thus don't know whether you haven't already discussed some of these
> issues, I hesitate to go ahead and edit the proposal. But I could do the
> changes myself if you agree with a change proposal and if nobody else
> adjusts the document accordingly.
>
> All the best
> Adrian
>
> [1] See https://twitter.com/pampel/status/411128690828140544 and
> http://wisspub.net/impressum/ .
>
>
>
>
>>>> On 13.12.2013 at 5:20, Dan Scott <denials@gmail.com> wrote:
>> On Thu, Dec 12, 2013 at 6:58 PM, Niklas Lindström
> <lindstream@gmail.com> wrote:
>>> Hello again,
>>>
>>> The microdata is now fixed in the following ways:
>>>
>>> * corrected some itemtype values, which microdata requires to be
> full URLs
>>> (unlike RDFa, which can use @vocab to avoid repetition)
>>> * the items are linked together using isPartOf
>>> * the same entities are described throughout (instead of six
> disjoint
>>> entities), using @itemid
>>>
>>> I used @itemid this time, since at least microdata parsers producing
> RDF get
>>> the data right. Unfortunately, @itemid is (also) required to be a
> full URL
>>> in microdata, and it is only allowed if both itemscope and itemtype
> are also
>>> present. It's either that or using @itemref, which as I showed
> earlier [1]
>>> is also somewhat cumbersome (it requires you to sprinkle in @id and
> glue
>>> items together from disparate parts). Though if anyone more versed
> in
>>> microdata can clean it up, please do.
>>>
>>> I also added an RDFa version (which I find to be less verbose). I
> really
>>> recommend to paste that into RDFa Play [2].
>>>
>>> The examples are verified (using RDFLib) to produce the also added
> Turtle
>>> example (minus some web page related details).
>>>
>>> (Apart from considering the weight of the markup (which gets heavy
> with this
>>> much granularity in once place), the Turtle is what I usually focus
> on when
>>> I reason about the merits and flaws of various properties, types and
> uses
>>> thereof.)
>>
>> Awesome, thanks for fixing this up, Niklas! I was enjoying a visit
>> with Santa at our local public library. Well, my kids enjoyed it too
>> :)
>>
>>> I also added a variant with less verbose precision (but using the
> same
>>> properties of course): just an Article linked to a PeriodicalIssue
> (skipping
>>> the volume and periodical). Notice that name, volumeNumber and issn
> is used
>>> on the PeriodicalIssue, indicating that those are, scruffily,
> "inherited"
>>> from the collections above. That's the kind of flexibility I believe
> we're
>>> after.
>>
>> Hmm. I think that might be _too_ scruffy; that example hangs the
> issn,
>> volumeNumber, and periodical name off of PublicationIssue, which is
>> not valid according to the proposal that we're putting forward, and
>> therefore wouldn't be expected to be parsed correctly by the search
>> engines, right? (I took a quick stab at sorting it out but then
>> realized that the result was going to pretty much mirror the core
>> example...).
>>
>> Thanks,
>> Dan
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 13 December 2013 16:28:57 UTC