Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mention nanpublications' applicability in RDFa #18

Open
csarven opened this issue Aug 6, 2014 · 4 comments
Open

Mention nanpublications' applicability in RDFa #18

csarven opened this issue Aug 6, 2014 · 4 comments

Comments

@csarven
Copy link

csarven commented Aug 6, 2014

I think the main challenge revolves around context URIs in RDFa. It is unclear to me at least at this point if/how np:Assertion, np:Provenance, and np:PublicationInfo can exist in the same RDFa document where np:Nanopublication sits. While it would be possible to spread the rdfg:Graphs into different deferenceable URIs (i.e., away from the current document where np:Nanopublicatoin) is in, it introduces an extra layer to jump around to collect the complete information. That might be a problem for "copy/paste" scenarios for nanopublications.

Perhaps I'm missing something obvious here, so if someone can enlighten me, that'd be great.

@tkuhn
Copy link
Member

tkuhn commented Aug 6, 2014

I am not sure nanopublications can be represented in RDFa. I have never tried and I am not an expert in RDFa. Nanopublications are typically represented in TriG, TriX, N-Quads, or queried via SPARQL from a triple store. They are seen as independent entities not typically embedded in a HTML document (though this might be a nice thing to have).

@csarven
Copy link
Author

csarven commented Aug 6, 2014

IMO, having Nanopublications in RDFa should be the driving factor. When machine-friendly "papers" are in RDFa, it would be possible to capture those essential bits.

Besides, why lock out an W3C recommendation right off the start?

@csarven
Copy link
Author

csarven commented Aug 6, 2014

@tkuhn As an example, please take a look under the hood http://csarven.ca/sense-of-lsd-analysis

If RDFa is locked out of reasonable way of making Nanopublications i.e., within the same document, I don't see how there is a major need for Nanopublications. One would simply point at the source dataset URL, or point at other URIs for the metadata. It seems like it is adding an additional layer when there is no need to. In this case, one could get away with HTML/microformats for instance. What am I missing?

@tkuhn
Copy link
Member

tkuhn commented Aug 6, 2014

Nanopublications are not designed as annotations to classical publications but as independent entities. Nanopublications do not need to be linked to any kind of (PDF/HTML) publication, and if they are, there could be thousands or even millions of nanopubs for a single classical publication (definitely more than what you want to have embedded in an HTML file). In other words, nanopubs typically don't just link to a dataset, they are the dataset. So, I think the basic philosophy is very different from what you describe above. Have a look, for example, at the following publications for an introduction and motivation of the nanopublication approach:

Still, there is no intention to lock out RDFa, and if there is a nice way of how to represent nanopubs in RDFa, I'd be all for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants