I have looked at something very different with regards to RDFLib, namely what kind of changes should be done in RDFLib to make it compatible with the upcoming RDF 1.1. I realize RDF 1.1 is still in development, but I think the core features are pretty much stable now. It would be great if RDFLib was one of the first such libraries to be prepared for RDF 1.1. (Actually, it would be great if RDFLib was one of the official test implementation in the Candidate Recommendation phase, but requires some stars to line up, e.g., our own schedules...).
I have identified four different areas: Datasets, skolemization features, XMLLiteral and HTML Literal updates, and changes in plain literals. I have implemented the proposed changes for the first three because they are, in general, straightforward; the fourth may require some decision, so I did not touch it yet. I will send four separate mails on the four subjects in what follows, to clearly separate the issues and the corresponding threads.
Of course, this implementation resides only on my machine, nothing on github yet. If we agree with the general lines then, I presume, what I have to do is to create a separate branch. Maybe it is better if I do that once the rdflib official branch merges with the rdfa+microdata branch that I created, just to avoid proliferation (but you may tell me it is fine, and you can always take care of the github merge magic...)
So, watch the incoming mails...
Ivan
P.S. Gregg, I have added you because, although you are not a Python/RDFLib user, you may want to do something similar for Ruby. And you and I always think in parallel:-)
----
Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net
Having RDFLib as an official test implementation of rdf 1.1 would of
course be great.
It would be great if you could share your code with us straight away -
either in a branch of rdflib or in a separate project.
Merging later I can do, and it should be easy (tm) (I also hope to
merge the structured parsers branch one of the next few days)
Once we have the code it's also easier to comment on the issues!
Thanks!
- Gunnar
On 5 November 2012 17:34, Ivan Herman <ivan.her...@gmail.com> wrote:
> I have looked at something very different with regards to RDFLib, namely what kind of changes should be done in RDFLib to make it compatible with the upcoming RDF 1.1. I realize RDF 1.1 is still in development, but I think the core features are pretty much stable now. It would be great if RDFLib was one of the first such libraries to be prepared for RDF 1.1. (Actually, it would be great if RDFLib was one of the official test implementation in the Candidate Recommendation phase, but requires some stars to line up, e.g., our own schedules...).
> I have identified four different areas: Datasets, skolemization features, XMLLiteral and HTML Literal updates, and changes in plain literals. I have implemented the proposed changes for the first three because they are, in general, straightforward; the fourth may require some decision, so I did not touch it yet. I will send four separate mails on the four subjects in what follows, to clearly separate the issues and the corresponding threads.
> Of course, this implementation resides only on my machine, nothing on github yet. If we agree with the general lines then, I presume, what I have to do is to create a separate branch. Maybe it is better if I do that once the rdflib official branch merges with the rdfa+microdata branch that I created, just to avoid proliferation (but you may tell me it is fine, and you can always take care of the github merge magic...)
> So, watch the incoming mails...
> Ivan
> P.S. Gregg, I have added you because, although you are not a Python/RDFLib user, you may want to do something similar for Ruby. And you and I always think in parallel:-)
> ----
> Ivan Herman
> 4, rue Beauvallon, clos St Joseph
> 13090 Aix-en-Provence
> France
> http://www.ivan-herman.net
On Nov 6, 2012, at 04:15 , Gunnar Aastrand Grimnes wrote:
> Great work Ivan!
> Having RDFLib as an official test implementation of rdf 1.1 would of
> course be great.
> It would be great if you could share your code with us straight away -
> either in a branch of rdflib or in a separate project.
I think I would prefer to use the same approach as for RDFa, namely to put it up as a separate branch. I would still have to find out how to do that; I presume I will have to merge what I have (in a separate repository) with the latest branch in master, and then find out again how one creates a new branch in SourceFile:-)
> Merging later I can do, and it should be easy (tm) (I also hope to
> merge the structured parsers branch one of the next few days)
> Once we have the code it's also easier to comment on the issues!
> Thanks!
> - Gunnar
> On 5 November 2012 17:34, Ivan Herman <ivan.her...@gmail.com> wrote:
>> Gunnar, everybody,
>> I have looked at something very different with regards to RDFLib, namely what kind of changes should be done in RDFLib to make it compatible with the upcoming RDF 1.1. I realize RDF 1.1 is still in development, but I think the core features are pretty much stable now. It would be great if RDFLib was one of the first such libraries to be prepared for RDF 1.1. (Actually, it would be great if RDFLib was one of the official test implementation in the Candidate Recommendation phase, but requires some stars to line up, e.g., our own schedules...).
>> I have identified four different areas: Datasets, skolemization features, XMLLiteral and HTML Literal updates, and changes in plain literals. I have implemented the proposed changes for the first three because they are, in general, straightforward; the fourth may require some decision, so I did not touch it yet. I will send four separate mails on the four subjects in what follows, to clearly separate the issues and the corresponding threads.
>> Of course, this implementation resides only on my machine, nothing on github yet. If we agree with the general lines then, I presume, what I have to do is to create a separate branch. Maybe it is better if I do that once the rdflib official branch merges with the rdfa+microdata branch that I created, just to avoid proliferation (but you may tell me it is fine, and you can always take care of the github merge magic...)
>> So, watch the incoming mails...
>> Ivan
>> P.S. Gregg, I have added you because, although you are not a Python/RDFLib user, you may want to do something similar for Ruby. And you and I always think in parallel:-)
>> ----
>> Ivan Herman
>> 4, rue Beauvallon, clos St Joseph
>> 13090 Aix-en-Provence
>> France
>> http://www.ivan-herman.net
I hope I have not made a mess (I am always a little bit wary still of what happens in github, I am not used to it...) but I think I successfully created a branch called 'rdf11'; I pulled the latest master branch and got it merged with what I did and pushed it back.
> On Nov 6, 2012, at 04:15 , Gunnar Aastrand Grimnes wrote:
>> Great work Ivan!
>> Having RDFLib as an official test implementation of rdf 1.1 would of
>> course be great.
>> It would be great if you could share your code with us straight away -
>> either in a branch of rdflib or in a separate project.
> I think I would prefer to use the same approach as for RDFa, namely to put it up as a separate branch. I would still have to find out how to do that; I presume I will have to merge what I have (in a separate repository) with the latest branch in master, and then find out again how one creates a new branch in SourceFile:-)
> I will take care of it sometimes this week.
> Ivan
>> Merging later I can do, and it should be easy (tm) (I also hope to
>> merge the structured parsers branch one of the next few days)
>> Once we have the code it's also easier to comment on the issues!
>> Thanks!
>> - Gunnar
>> On 5 November 2012 17:34, Ivan Herman <ivan.her...@gmail.com> wrote:
>>> Gunnar, everybody,
>>> I have looked at something very different with regards to RDFLib, namely what kind of changes should be done in RDFLib to make it compatible with the upcoming RDF 1.1. I realize RDF 1.1 is still in development, but I think the core features are pretty much stable now. It would be great if RDFLib was one of the first such libraries to be prepared for RDF 1.1. (Actually, it would be great if RDFLib was one of the official test implementation in the Candidate Recommendation phase, but requires some stars to line up, e.g., our own schedules...).
>>> I have identified four different areas: Datasets, skolemization features, XMLLiteral and HTML Literal updates, and changes in plain literals. I have implemented the proposed changes for the first three because they are, in general, straightforward; the fourth may require some decision, so I did not touch it yet. I will send four separate mails on the four subjects in what follows, to clearly separate the issues and the corresponding threads.
>>> Of course, this implementation resides only on my machine, nothing on github yet. If we agree with the general lines then, I presume, what I have to do is to create a separate branch. Maybe it is better if I do that once the rdflib official branch merges with the rdfa+microdata branch that I created, just to avoid proliferation (but you may tell me it is fine, and you can always take care of the github merge magic...)
>>> So, watch the incoming mails...
>>> Ivan
>>> P.S. Gregg, I have added you because, although you are not a Python/RDFLib user, you may want to do something similar for Ruby. And you and I always think in parallel:-)
>>> ----
>>> Ivan Herman
>>> 4, rue Beauvallon, clos St Joseph
>>> 13090 Aix-en-Provence
>>> France
>>> http://www.ivan-herman.net
> Wow. That is a major step... I have refreshed the repository on my machine so, from this point on, if I do any changes, that would go directly into the main branch!
> Thanks Gunnar
No thank you! You did all the work and you built in on top of rdflib!
I just did the admin-merge :)
> I hope I have not made a mess (I am always a little bit wary still of what happens in github, I am not used to it...) but I think I successfully created a branch called 'rdf11';
> I pulled the latest master branch and got it merged with what I did and pushed it back.
Dont worry - I also have to think twice and test three times when git
branching/merging - but this looks good to me!
