Open Klortho opened 10 years ago
Dear all,
I have some concerns here.
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ; :expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642 Additional comments / discussion?
I’m fine with the owl:sameAs relation to the pubmed article – as Chris told us previously, they both are two URLs representing the same work.
Still, the use of rdfs:seeAlso (Chris, you missed an “s” in the prefix) is still a valuable option, since one can associate it to whatever (s)he wants. However, my concern is (let me be Devil’s advocate here) why we would specify it to the Work level, instead of specifying it to the Expression level, or even to both levels? In addition, why we should not add also:
pmc:PMC3159421 owl:seeAlso http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/?
Finally, I have several concerns about the use of foaf:homepage. Taking the FOAF documentation, we have that:
“The homepage property relates something to a homepage about it. [cut] A 'homepage' in this sense is a public Web document, typically but not necessarily available in HTML format. The page has as a topic the thing whose homepage it is.”
Thus, according to the definition, an homepage is a Web document that talks about our Work, i.e., the Work in consideration is the main topic discussed in that page. However, http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is not an homepage discussing pmc:PMC3159421 as a primary topic, rather it is (some sort of concrete representation of) that Work!
Maybe the difference between “talks about” and “is” is subtle, but it is crucial in my opinion.
In addition, I think could be valuable to add FaBiO relations to link directly to the item, in both Work and Expression. So, in my mind we should include also the following statements:
pmc:PMC3110795 fabio:hasPortrayal http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ . :expression_3110795 fabio:hasRepresentation http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ .
What do you think?
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
Hi,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples. The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right? A web page has none RDF triple in it... another nice thing about foaf:homepage is that it is inverse functional property, so if two URI link to the same web page through foaf:homepage, they are referring to the same thing.
I am still learning fabio ontology, so if you all agree that fabio:hasPortrayal and fabio:hasRepresentation can have web pages as property range, I am fine with them. Thanks!
Best, Gang :
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I’m concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn’t.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni essepuntato@cs.unibo.itwrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Silvio wrote,
... my concern is ... why we would specify [rdfs:seeAlso] to the Work level, instead of specifying it to the Expression level, or even to both levels?
The triple <http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/> ties the work to the PubMed abstract page for the work, not the expression. PMIDs are versioned just like PMCIDs, and so "21701575", without a version number, corresponds to the work. I don't have a problem with also creating an rdfs:seeAlso triple from the expression to this PubMed abstract page, but would resist linking the other way around.
So, let me try to update the example per the discussion here:
pmc:PMC3110795
owl:sameAs pubmed:21701575
* rdf:seeAlso <http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/> ;
rdf:seeAlso <http://www.ncbi.nlm.nih.gov/pubmed/21701575/> ;
fabio:hasPortrayal <http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/> .
:expression_3110795
frbr:realizationOf pmc:PMC3159421 ;
prism:doi "10.1371/journal.pone.0020642" ;
skos:closeMatch <http://dx.doi.org/10.1371/journal.pone.0020642> ;
* rdf:seeAlso <http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/> ;
rdf:seeAlso <http://www.ncbi.nlm.nih.gov/pubmed/21701575/> ;
fabio:hasRepresentation <http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/> .
The ones above marked with *
are redundant, and could be dropped, IMO.
Hi all,
So, if we remove the foaf:homepage, we would have
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ;
:expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat ( http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
Something that has not been mentioned is the reference to the JATS-XML
where the RDF is originated from. Following the same reasoning, we would
also have pmc:PMC3110785 rdfs:seeAlso
Cheers, Leyla
On Thu, Feb 13, 2014 at 5:04 PM, Gang Fu gangfu1982@gmail.com wrote:
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni essepuntato@cs.unibo.itwrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
I believe there is one thing that has not yet been mentioned. the license under which the publication has been released. In Biotea we modeled this as dcterms:license could the same be used in this new model we are discussing?
On Thu, Feb 13, 2014 at 3:44 PM, Leyla Jael García Castro leylajael@gmail.com wrote:
Hi all,
So, if we remove the foaf:homepage, we would have
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ;
:expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat (http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
Something that has not been mentioned is the reference to the JATS-XML where the RDF is originated from. Following the same reasoning, we would also have pmc:PMC3110785 rdfs:seeAlso
, and then we would have as well pmc:PMC3110785 dcterms:hasFormat . If we want to specify that the RDF was derived from the XML, we can also use pmc:PMC3110785 dcterms:source . At http://dublincore.org/documents/dcmi-terms/#terms-source says "The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system." In Biotea we used biotea:PMC3110785 dcterms:source http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 but that is not accurate as the real source is the XML, even when the HTML is another format of the XML. Cheers, Leyla
On Thu, Feb 13, 2014 at 5:04 PM, Gang Fu gangfu1982@gmail.com wrote:
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni essepuntato@cs.unibo.it wrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Alexander Garcia http://www.alexandergarcia.name/ http://www.usefilm.com/photographer/75943.html http://www.linkedin.com/in/alexgarciac
Any way to specify formats of linked items? Do we want to? (I can't see how it could be done without reifying the relationships, and in most cases, either the format will be HTML (web page) or else we won't know it, since it's not encoded in the JATS instance.)
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". ... The former is an RDF entity, while the latter is a web page.
This is not right. They are both RDF URIs. Maybe you were thrown by the fact that http://rdf.ncbi.nlm.nih.gov/pubmed/21701575, right now, happens to redirect to the pubmed page.
Hi Chris,
{quote} {quote} I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". ... The former is an RDF entity, while the latter is a web page. {quote} This is not right. They are both RDF URIs. Maybe you were thrown by the fact that http://rdf.ncbi.nlm.nih.gov/pubmed/21701575, right now, happens to redirect to the pubmed page. {quote}
My mistake, sorry, you are totally right. In that case, "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" is perfectly fine.
Cheers,
Hi all,
Alexander is right, we are missing the license, and dcterms:license seems pretty straight forward so + 1
As for Chris' comment
So, let me try to update the example per the discussion here:
pmc:PMC3110795 owl:sameAs pubmed:21701575
- rdf:seeAlso http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ; fabio:hasPortrayal http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ .
:expression_3110795 frbr:realizationOf pmc:PMC3159421 ; prism:doi "10.1371/journal.pone.0020642" ; skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642 ;
- rdf:seeAlso http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ; fabio:hasRepresentation http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ .
Why would be the ones starting with * redundant? Is it because the same link is the range in fabio:hasPortrayal and fabio:hasRepresentation? If yes, well, they are redundant but it would be simpler just querying for all rdf:seeAlso rather than seeAlso for PubMed link, but fabio:hasPortrayal for PMC link when talking about a Work and fabio:hasRepresentation when talking about an Expression.
Cheers, Leyla
On Thu, Feb 13, 2014 at 8:54 PM, Alexander Garcia Castro < alexgarciac@gmail.com> wrote:
I believe there is one thing that has not yet been mentioned. the license under which the publication has been released. In Biotea we modeled this as dcterms:license could the same be used in this new model we are discussing?
On Thu, Feb 13, 2014 at 3:44 PM, Leyla Jael García Castro leylajael@gmail.com wrote:
Hi all,
So, if we remove the foaf:homepage, we would have
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ;
:expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat (http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
Something that has not been mentioned is the reference to the JATS-XML where the RDF is originated from. Following the same reasoning, we would also have pmc:PMC3110785 rdfs:seeAlso
, and then we would have as well pmc:PMC3110785 dcterms:hasFormat . If we want to specify that the RDF was derived from the XML, we can also use pmc:PMC3110785 dcterms:source . At http://dublincore.org/documents/dcmi-terms/#terms-source says "The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system." In Biotea we used biotea:PMC3110785 dcterms:source http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 but that is not accurate as the real source is the XML, even when the HTML is another format of the XML. Cheers, Leyla
On Thu, Feb 13, 2014 at 5:04 PM, Gang Fu gangfu1982@gmail.com wrote:
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni <essepuntato@cs.unibo.it
wrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Alexander Garcia http://www.alexandergarcia.name/ http://www.usefilm.com/photographer/75943.html http://www.linkedin.com/in/alexgarciac
Hi Leyla,
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat ( http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
I believe Chris intended to make http://_rdf_. ncbi.nlm.nih.gov/pubmed/21701575 as an entity, instead of a web page. It is currently resolved as a web page, because it has not been implemented yet. http://_www_.ncbi.nlm.nih.gov/pubmed/21701575 is a web page. Based on my understanding, PubMed Central (PMC) provide full text, and PubMed only provide abstract, so they are not exactly same. If I remembered correctly, we use skos:closeMatch to link a PMC instance to a PubMed instance, right?
Best, Gang
On Thu, Feb 13, 2014 at 3:44 PM, Leyla Jael García Castro < leylajael@gmail.com> wrote:
Hi all,
So, if we remove the foaf:homepage, we would have
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ;
:expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat ( http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
Something that has not been mentioned is the reference to the JATS-XML where the RDF is originated from. Following the same reasoning, we would also have pmc:PMC3110785 rdfs:seeAlso
, and then we would have as well pmc:PMC3110785 dcterms:hasFormat . If we want to specify that the RDF was derived from the XML, we can also use pmc:PMC3110785 dcterms:source . At http://dublincore.org/documents/dcmi-terms/#terms-source says "The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system." In Biotea we used biotea:PMC3110785 dcterms:source http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 but that is not accurate as the real source is the XML, even when the HTML is another format of the XML. Cheers, Leyla
On Thu, Feb 13, 2014 at 5:04 PM, Gang Fu gangfu1982@gmail.com wrote:
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni essepuntato@cs.unibo.itwrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Why would be the ones starting with * redundant? Is it because the same link is the range in fabio:hasPortrayal and fabio:hasRepresentation? If yes, well, they are redundant but it would be simpler just querying for all rdf:seeAlso rather than seeAlso for PubMed link, but fabio:hasPortrayal for PMC link when talking about a Work and fabio:hasRepresentation when talking about an Expression.
I don't disagree. Okay, let's keep both.
Gang wrote:
If I remembered correctly, we use skos:closeMatch to link a PMC instance to a PubMed instance, right?
Hi, Gang, check this example again. I'm suggesting to link the rdf PMC and PubMed URIs as being owl:sameAs, and then linking from those to the www URIs with various rdfs:seeAlso, etc.
Hi Gang,
It was my mistake, the owl:sameAs in that case is indeed appropriate.
So, I think we have an agreement on this? I think the last example from Chris summarizes it all: pmc:PMC3110795 owl:sameAs pubmed:21701575 rdf:seeAlso http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ; fabio:hasPortrayal http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ .
:expression_3110795 frbr:realizationOf pmc:PMC3159421 ; prism:doi "10.1371/journal.pone.0020642" ; skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642 ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ; fabio:hasRepresentation http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ .
Not related to the identifiers but also mentioned in this thread: the license, that one is still missing so, using dcterms:license (has range dcterms:LicenseDocument --A legal document giving official permission to do something with a Resource), it could be like this.
:expression_3110795 dcterms:license < https://creativecommons.org/publicdomain/zero/1.0/legalcode>
I propose to attach the license to the Expression rather than the Work as it does not have to apply to all possible Expression.
Cheers, Leyla
On Fri, Feb 14, 2014 at 12:56 AM, Gang Fu gangfu1982@gmail.com wrote:
Hi Leyla,
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat ( http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
I believe Chris intended to make http://_rdf_. ncbi.nlm.nih.gov/pubmed/21701575 as an entity, instead of a web page. It is currently resolved as a web page, because it has not been implemented yet. http://_www_.ncbi.nlm.nih.gov/pubmed/21701575 is a web page. Based on my understanding, PubMed Central (PMC) provide full text, and PubMed only provide abstract, so they are not exactly same. If I remembered correctly, we use skos:closeMatch to link a PMC instance to a PubMed instance, right?
Best, Gang
On Thu, Feb 13, 2014 at 3:44 PM, Leyla Jael García Castro < leylajael@gmail.com> wrote:
Hi all,
So, if we remove the foaf:homepage, we would have
http://rdf.ncbi.nlm.nih.gov/pmc/PMC3110795 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 foaf:homepage http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ ; rdf:seeAlso http://www.ncbi.nlm.nih.gov/pubmed/21701575/ ;
:expression_3110795 frbr:realizationOf pmc:PMC3159421 prism:doi "10.1371/journal.pone.0020642" skos:closeMatch http://dx.doi.org/10.1371/journal.pone.0020642
I do not feel quite comfortable about "pmc:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575". It is true that both represent the same publication but are they really the same? The former is an RDF entity, while the latter is a web page. What about using dcterms:hasFormat ( http://dublincore.org/documents/dcmi-terms/#terms-hasFormat)? This property is defined as "A related resource that is substantially the same as the pre-existing described resource, but in another format" which seems to be what we want to describe.
In Biotea, we initially used biotea:PMC3110785 owl:sameAs http://rdf.ncbi.nlm.nih.gov/pubmed/21701575. But then we got a strong feedback about "http://rdf.ncbi.nlm.nih.gov/pubmed/21701575" not being an entity so we changed to rdfs:seeAlso.
Something that has not been mentioned is the reference to the JATS-XML where the RDF is originated from. Following the same reasoning, we would also have pmc:PMC3110785 rdfs:seeAlso
, and then we would have as well pmc:PMC3110785 dcterms:hasFormat . If we want to specify that the RDF was derived from the XML, we can also use pmc:PMC3110785 dcterms:source . At http://dublincore.org/documents/dcmi-terms/#terms-source says "The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system." In Biotea we used biotea:PMC3110785 dcterms:source http://rdf.ncbi.nlm.nih.gov/pubmed/21701575 but that is not accurate as the real source is the XML, even when the HTML is another format of the XML. Cheers, Leyla
On Thu, Feb 13, 2014 at 5:04 PM, Gang Fu gangfu1982@gmail.com wrote:
Hi Silvio,
I got you. Thank you very much for your explanation. I am fine with frbr properties then.
Best, Gang
On Thu, Feb 13, 2014 at 9:43 AM, Silvio Peroni essepuntato@cs.unibo.itwrote:
Hi Gang, all,
I think the idea of using foaf:homepage was proposed by me. The reason I suggest foaf:homepage is that the range of this inverse functional property is a web page instead of a URI of RDF triples.
I was not criticising that particular intensional characteristic of foaf:homepage (i.e., the inverse functional characteristic). That, indeed, is a quite useful feature to infer additional owl:sameAs relations.
What I'm concerned about is the actual extensional meaning of such a property, i.e., that conveyed through the natural language definition of such a property. And, according to that definition, the use of foaf:homepage proposed in previous emails to link Works to concrete objects, such as a document available on the Web, is totally wrong, in my opinion.
The ranges of both fabio:hasPortrayal and fabio:hasRepresentation are fabio:item. I guess fabio:item should be a URI of RDF triples, instead of a web page, right?
No, it isn't.
Just to clarify, in FRBR any Item refers to a concrete object. Now, since the HTML page available at the URL http://www.ncbi.nlm.nih.gov/pmc/PMC3110795/ is a concrete object (i.e., it exists, it is tangible (digitally speaking): it is a file stored on a particular storage medium, i.e., the Web), it can be linked from the FRBR Work and FRBR Expression layers through such FaBiO properties without any problem, since that URL actually represents a FRBR Item indeed.
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- You received this message because you are subscribed to the Google Groups "JATS2RDF" group. To unsubscribe from this group and stop receiving emails from it, send an email to jats2rdf+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Dear Leyla, all,
Not related to the identifiers but also mentioned in this thread: the license, that one is still missing so, using dcterms:license (has range dcterms:LicenseDocument --A legal document giving official permission to do something with a Resource), it could be like this.
:expression_3110795 dcterms:license https://creativecommons.org/publicdomain/zero/1.0/legalcode
I propose to attach the license to the Expression rather than the Work as it does not have to apply to all possible Expression.
Mhn… about licensing: I totally agree with you that it shouldn’t be a property of the Work, but I’m not sure should be a property of the Expression.
I mean, in principle I thought that the license only refers to the Expression, as you, Leyla, suggested. However, I fear I’ve not the whole picture in mind. For instance, is it possible to have the PubMed HTML document of an article with one license and the Balisage HTML document of the same article with another license?
If this scenario is possible, then the licence should apply to the Item level. Otherwise, if it is always true that all the items share the same licence since it actually refer to the content, then we can apply it to the Expression.
What do you think?
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
is it possible to have the PubMed HTML document of an article with one license and the Balisage HTML document of the same article with another license
I don't think so, not if they are two manifestations of the same expression. I would say we should stick the license property on the expression (two different expressions certainly could have different licenses -- like author manuscript vs. final published version). Also, we lack any information in the JATS instance document to do anything else (and again, I think trying to go below expression makes things too complicated.)
I made issue #21 for this: https://github.com/Klortho/eutils-org/issues/21
Chris
On Sat, Feb 15, 2014 at 3:13 AM, S. notifications@github.com wrote:
Dear Leyla, all,
Not related to the identifiers but also mentioned in this thread: the license, that one is still missing so, using dcterms:license (has range dcterms:LicenseDocument --A legal document giving official permission to do something with a Resource), it could be like this.
:expression_3110795 dcterms:license < https://creativecommons.org/publicdomain/zero/1.0/legalcode>
I propose to attach the license to the Expression rather than the Work as it does not have to apply to all possible Expression.
Mhn… about licensing: I totally agree with you that it shouldn’t be a property of the Work, but I’m not sure should be a property of the Expression.
I mean, in principle I thought that the license only refers to the Expression, as you, Leyla, suggested. However, I fear I’ve not the whole picture in mind. For instance, is it possible to have the PubMed HTML document of an article with one license and the Balisage HTML document of the same article with another license?
If this scenario is possible, then the licence should apply to the Item level. Otherwise, if it is always true that all the items share the same licence since it actually refer to the content, then we can apply it to the Expression.
What do you think?
Have a nice day :-)
S.
Silvio Peroni, Ph.D. Department of Computer Science and Engineering University of Bologna, Bologna (Italy) Tel: +39 051 2094871 E-mail: essepuntato@cs.unibo.it Web: http://www.essepuntato.it Blog: http://palindrom.es/phd Twitter: essepuntato
—
Reply to this email directly or view it on GitHubhttps://github.com/Klortho/eutils-org/issues/19#issuecomment-35150046 .
As was discussed on an email thread "sameAs to DOI URL and authors order", we need to (re)implement some links to identifiers. Review how they're done now and fix as necessary.
Example: PMC3110795. This id "PMC3110795" corresponds to the FRBR work, and "PMC3110795.1" corresponds to the expression. The XML document describes the expression, but there is no reference to the version-numbered ID in the document.
This article has:
So I think we have consensus on these relationships:
Additional comments / discussion?