How to create a database for unknown kinds of data? I am in the process of designing a database for a new PHP/MySql-based application.

My problem is that I do not and cannot represent what should be saved in the database because it is unlimited and changing.

Here is the problem example:
The application will be a shopping website that has many kind of products all of them have some shared attributes such as title and price but some kinds have specific details such as expiry date some have isbn some non.

This is just an example but I really have many kinds with many different attributes.

I can create a table for each kinds, but what I have is not all the available kinds, many kinds of items are unknown at this time.

Is their a way to accommodate this problem without over head in the user's side?
Unknown kinds of data sounds to me somewhat fishy.  Your examples, of course, are all knowns.  For goods and services careful analysis and normalization are important and I think you can get away from EAV modelling (which I think will cause mor problems than it solves) for core data.  The rest could be stuffed in XML fields or the like.  Additionally if you do your design right you can always expand the information appropriately.  Consider the following three tables:

CREATE TABLE products (
    id int autoincrement primary key,
    sellprice numeric,
    part_code varchar(10),
    title varchar(32),
    description text
);

CREATE TABLE barcode_type (
    id int autoincrement primary key,
    label varchar(15) not null unique
);

CREATE TABLE make_model (
    id int autoincrement primary key,
    make varchar(15) not null,
    model varchar(15),
    barcode_type int references barcode_type(id),
    barcode varchar(32)
);


Now with this you can assign barcodes (including ISBN, EAN, UPC, etc, to various parts, one per make/model combination.  If you need to support more barcode types, this is not hard to add.  As far as expiration dates, where these go depends on where you are tracking them.  If you want to have temporary pricing, or pricing for groups of customers, you can add that too.

However what you are describing doesn't sound very unstructured.  I would suggest starting with a minimal design and expanding as needed rather than an EAV design and later regretting it.