Semantic proposals are hosted on github
-
Alexey Zakhlestine
Semantic proposals are hosted on github
Fri July 23 2010 10:00:07 UTCFollowing several requests I moved semantic proposals from Google Wave to github:
You can find them here:
http://github.com/midgardproject/proposals/tree/master/Semantic%20Data/
I gave push-access to everyone I could remember. Please tell me if you need access and you don't have it.
p.s. we really need your opinions
--
Alexey Zakhlestin
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Semantic proposals are hosted on github
Mon August 02 2010 09:25:05 UTCHi!
> Following several requests I moved semantic proposals from Google Wave to github:
>
> You can find them here:
>
> http://github.com/midgardproject/proposals/tree/master/Semantic%20Data/
Regarding implementation details.
## Goals:
* Semantic Data implementation is a must
* We need to think about transition path from Midgard2 to Midgard3
* Midgard3 should be much more flexible than Midgard2
## Proposals:
1. Provide MidgardSchemaStorage abstraction layer
* We do not limit schema generation for one implementation
* We can easily provide backward compatible schemas
* Other languages can make own implementations without mapping overhead
2. Provide MidgardReplicator abstraction layer
* Let language bindings do their own (de)serializations
* Import and export can be implemented for particular schemas layout
3. Keep MidgardDBObject as is. It's designed for direct and "raw" table
usage.
4. Keep MidgardObject as is.
* We can rename this class, if we do not need it for direct future usage.
* It'll be helpful with for Midgard 2->3 migration.
5. Add MidgardRDFObject class which extends MidgardDBObject.
* We do not drop any exisiting features, and we extend them instead.
* We can easily convert RDF objects to fixed MidgardDBObject
With this approach Midgard3 can act as:
* ORM or Active Record backend
* Traditional Midgard2 Content Repository
* RDF compatible, triplestore like repository
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Semantic proposals are hosted on github
Mon August 02 2010 09:55:05 UTCOn 02.08.2010, at 13:15, Piotr Pokora wrote:
> Hi!
>
>> Following several requests I moved semantic proposals from Google Wave to github:
>>
>> You can find them here:
>>
>> http://github.com/midgardproject/proposals/tree/master/Semantic%20Data/
>
> Regarding implementation details.
>
> ## Goals:
>
> * Semantic Data implementation is a must
> * We need to think about transition path from Midgard2 to Midgard3
> * Midgard3 should be much more flexible than Midgard2
>
> ## Proposals:
>
> 1. Provide MidgardSchemaStorage abstraction layer
>
> * We do not limit schema generation for one implementation
> * We can easily provide backward compatible schemas
> * Other languages can make own implementations without mapping overhead
the whole idea of defining this in terms of API instead of in terms of schema-files is to have such abstraction.
so, we just need to make sure, that API is flexible-enough to support RDF-style schemas
>
> 2. Provide MidgardReplicator abstraction layer
>
> * Let language bindings do their own (de)serializations
> * Import and export can be implemented for particular schemas layout
so, again, we should just provide basic API, which will be used be applications to invent their own replication strategies
> 3. Keep MidgardDBObject as is. It's designed for direct and "raw" table
> usage.
>
> 4. Keep MidgardObject as is.
>
> * We can rename this class, if we do not need it for direct future usage.
> * It'll be helpful with for Midgard 2->3 migration.
>
> 5. Add MidgardRDFObject class which extends MidgardDBObject.
>
> * We do not drop any exisiting features, and we extend them instead.
> * We can easily convert RDF objects to fixed MidgardDBObject
I don't like idea of having "RDF" in name. We should, instead, define it in terms of Logical objects and Physical db-mappers.
Probably, we don't need additional objects at all. we just introduce mappers underneath, and if mapper strictly maps logical object to physical db-row we get backwards-compatible solution.
This way, we are left with current MidgardDBObject and MidgardObject classes.
We _can_ introduce additional MidgardRawDBObject, which will take care of low-level operations, but I think it will just complicate things.
It is not a good idea to implement queries on Logical objects in terms of API calls to "Physical" objects. Logical objects should let mapper generate optimal SQL query depending on situation.
>
> With this approach Midgard3 can act as:
>
> * ORM or Active Record backend
> * Traditional Midgard2 Content Repository
> * RDF compatible, triplestore like repository
Yes, these all should work with midgard3, as midgard3 will be the superset of midgard2.
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Semantic proposals are hosted on github
Mon August 02 2010 10:05:04 UTCHi!
>>
>> 1. Provide MidgardSchemaStorage abstraction layer
>>
>> * We do not limit schema generation for one implementation
>> * We can easily provide backward compatible schemas
>> * Other languages can make own implementations without mapping overhead
>
> the whole idea of defining this in terms of API instead of in terms of schema-files is to have such abstraction.
> so, we just need to make sure, that API is flexible-enough to support RDF-style schemas
>
>>
>> 2. Provide MidgardReplicator abstraction layer
>>
>> * Let language bindings do their own (de)serializations
>> * Import and export can be implemented for particular schemas layout
>
> so, again, we should just provide basic API, which will be used be applications to invent their own replication strategies
Yes. API just have to describe what can be done.
File, memory, database or stream "storage" should be done by particular
implementation.
>> 3. Keep MidgardDBObject as is. It's designed for direct and "raw" table
>> usage.
>>
>> 4. Keep MidgardObject as is.
>>
>> * We can rename this class, if we do not need it for direct future usage.
>> * It'll be helpful with for Midgard 2->3 migration.
>>
>> 5. Add MidgardRDFObject class which extends MidgardDBObject.
>>
>> * We do not drop any exisiting features, and we extend them instead.
>> * We can easily convert RDF objects to fixed MidgardDBObject
>
> I don't like idea of having "RDF" in name. We should, instead, define it in terms of Logical objects and Physical db-mappers.
> Probably, we don't need additional objects at all. we just introduce mappers underneath, and if mapper strictly maps logical object to physical db-row we get backwards-compatible solution.
> This way, we are left with current MidgardDBObject and MidgardObject classes.
I just used RDF in name to make things clear here.
> We _can_ introduce additional MidgardRawDBObject, which will take care of low-level operations, but I think it will just complicate things.
> It is not a good idea to implement queries on Logical objects in terms of API calls to "Physical" objects. Logical objects should let mapper generate optimal SQL query depending on situation.
This is what MidgardDBObject does. It's raw table access representation.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Semantic proposals are hosted on github
Mon August 02 2010 10:10:05 UTCOn 02.08.2010, at 13:55, Piotr Pokora wrote:
>>> 3. Keep MidgardDBObject as is. It's designed for direct and "raw" table
>>> usage.
>>>
>>> 4. Keep MidgardObject as is.
>>>
>>> * We can rename this class, if we do not need it for direct future usage.
>>> * It'll be helpful with for Midgard 2->3 migration.
>>>
>>> 5. Add MidgardRDFObject class which extends MidgardDBObject.
>>>
>>> * We do not drop any exisiting features, and we extend them instead.
>>> * We can easily convert RDF objects to fixed MidgardDBObject
>>
>> I don't like idea of having "RDF" in name. We should, instead, define it in terms of Logical objects and Physical db-mappers.
>> Probably, we don't need additional objects at all. we just introduce mappers underneath, and if mapper strictly maps logical object to physical db-row we get backwards-compatible solution.
>> This way, we are left with current MidgardDBObject and MidgardObject classes.
>
> I just used RDF in name to make things clear here.
>
>> We _can_ introduce additional MidgardRawDBObject, which will take care of low-level operations, but I think it will just complicate things.
>> It is not a good idea to implement queries on Logical objects in terms of API calls to "Physical" objects. Logical objects should let mapper generate optimal SQL query depending on situation.
>
> This is what MidgardDBObject does. It's raw table access representation.
ok.
MidgardDBObject raw access to db-rows
MidgardObject abstracted access to data-objects
MidgardObject uses MidgardMapper (or however it will be named) for data-access.
MidgardMapper does not use MidgardDBObject, it generates optimized SQL queries for various situations.
if some MidgardObject is mapped to data-table directly, then queries on this MidgardObject will be equivalent to queries on similar MidgardDBObjects
does this sound ok? :)
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Semantic proposals are hosted on github
Mon August 02 2010 10:25:05 UTCHi,
On Mon, Aug 2, 2010 at 1:02 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> MidgardDBObject raw access to db-rows
> MidgardObject abstracted access to data-objects
>
> MidgardObject uses MidgardMapper (or however it will be named) for data-access.
> MidgardMapper does not use MidgardDBObject, it generates optimized SQL queries for various situations.
>
> if some MidgardObject is mapped to data-table directly, then queries on this MidgardObject will be equivalent to queries on similar MidgardDBObjects
Sounds like a good plan.
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
