search

relaton / relaton-w3c

MIT License
2 stars 1 forks source link

Former editors #5

Closed andrew2net closed 4 years ago

andrew2net commented 4 years ago

Do we need to parse Former editors?

image

If yes what type of contributor shuld we use?

ronaldtse commented 4 years ago

@andrew2net it would be better to handle them. Maybe we can add a type of contributor as "former contributor"?

Ping @opoudjis . This will have to go into relaton-model?

opoudjis commented 4 years ago

Yes it will, but no need to change relaton-models, the relation can already be expressed.

<role type="editor">
<description>former editor</description>
</role>

Recall that we want to keep role/@type very tightly constrained, whereas the description lets us refine the 6 types of contributor as much as you want.

I really, really don't see that we need to add different types of contributors or roles here; this works fine. We will need the caveat that former editors may need to be treated separately from current editors; but usually those former editors will be included in the bibliographic entry anyway.

opoudjis commented 4 years ago

I can't close this issue, btw...

ronaldtse commented 4 years ago

Not trying to crash the party but CSA documents have roles for “contributor to 1.0”, “contributor to 2.0” etc (suppose the version now is 2.0). Maybe there is a need for slightly more complex relations here?

opoudjis commented 4 years ago

Exactly the same solution: "description" after all is free text.

I see the temptation to link editors to editions by expanding the metadata around the role. DO NOT DO IT. The proper way to do this is to embed those editors of previous versions into related bibliographic items. That keeps the contributor relation simple, and puts the editor where they actually belong, on a previous edition:

<bibitem>
<contributor>
<role type="editor">
<person>CURRENT EDITOR</person>
</contributor>
<edition>2.0</edition>
....
<relation type="instance">
<bibitem>
<contributor>
<role type="editor">
<person>PREVIOUS EDITOR</person>
</contributor>
<edition>1.0</edition>
</bibitem>
</relation>
</bibitem>

Rendering can be made to navigate that; but making role into spaghetti helps nobody.

ronaldtse commented 4 years ago

The proper way to do this is to embed those editors of previous versions into related bibliographic items.

You're right. Now the question becomes -- can a document carry the previous version's metadata?

andrew2net commented 4 years ago

The document has Former editors:

but it's previous version has Editors:

seems the former editors don't match to the editors of the previous document version.

UPD I see, link to the previous version actually is the link to the previous date.

ronaldtse commented 4 years ago

I'm not seeing what you mean?

https://www.w3.org/TR/2020/CR-json-ld11-20200305/

Screen Shot 2020-03-29 at 11 14 27 PM

https://www.w3.org/TR/2020/CR-json-ld11-20200316/

Screen Shot 2020-03-29 at 11 14 42 PM

I only see "Markus Lanthaler (Graz University of Technology)" changing to "Markus Lanthaler (Google)".

The actual JSON-LD 1.0 document seems to be this: https://www.w3.org/TR/2014/REC-json-ld-20140116/

Linked from the latest document:

Screen Shot 2020-03-29 at 11 17 35 PM
andrew2net commented 4 years ago

@ronaldtse you are right. "Latest Recommendation" or "Previous Recommendation" is the link to the previous version. Suppose we should include the previous version as "obsoleted" relation, do we?

ronaldtse commented 4 years ago

Suppose we should include the previous version as "obsoleted" relation, do we?

Agree!

opoudjis commented 4 years ago

Yup, that's the way forward. A bit of pain for your traversal, because "former editor" is so much easier; but it will pay off.

In the worst case that you cannot recover the edition that the former editors were invovled with, just make up a dummy record with no edition number that this work obsoletes, and stick them in there. But it sounds like you can recover it from this presentation.